oasis standards track work product · web viewthis document defines the legalxml electronic court...
Post on 20-May-2018
213 Views
Preview:
TRANSCRIPT
Electronic Court Filing Version 40150OASIS Standard
23 May 2013
Committee Specification Draft 03 Public Review Draft 03Working Draft 021
21 February20121720 September 20153Specification URIsThis version
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-osdoc (Authoritative)httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-oshtml httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-ospdf NATODO
Previous versionhttpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-osdoc (Authoritative)httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-oshtml httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-ospdf httpwwwoasis-openorgcommitteesdownloadphp45646ecf-v401-spec-csprd03ziphttpwwwoasis-openorgcommitteesdownloadphp43732ecf-spec-v401-csprd02zip
Latest versionhttpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-spececf-v401-specdoc (Authoritative)httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-spececf-v401-spechtmlhttpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-spececf-v401-specpdfNATODO
Technical CommitteeOASIS LegalXML Electronic Court Filing TC
ChairsJames Cabral (jcabralmtgmccom) MTG Management ConsultantsJim Harris (jharrisncscorg) National Center for State Courts
EditorsAdam Angione (aangionecourthousenewscom) Courthouse News ServiceJames Cabral (jcabralmtgmccom) MTG Management Consultants
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 1 of 61
SECRETARY Additional artifacts
This prose specification is one component of a Work Product which also includes XML schemas
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosxsd XML sample messages
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosxml Model
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosmodel Genericode code lists
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosgc Related work
This specification replaces or supersedes OASIS LegalXML Electronic Court Filing Version 30 15 November 2005
httpdocsoasis-openorglegalxml-courtfilingspecsecfv30 OASIS Electronic Court Filing Version 40 21 September 2008
httpdocsoasis-openorglegalxml-courtfilingspecsecfv40ecf-v40-spec OASIS Electronic Court Filing Version 401 23 May 2013
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specThis specification is related to National Information Exchange Model 320
Declared XML namespacesurnoasisnamestclegalxml-courtfilingschemaxsdAppInfo-4050urnoasisnamestclegalxml-courtfilingschemaxsdAppellateCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdBankruptcyCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdCaseListQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCaseListResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCaseQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCaseResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCitationCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdCivilCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdCommonTypes-4050urnoasisnamestclegalxml-courtfilingschemaxsdCoreFilingMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCourtPolicyQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCourtPolicyResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCriminalCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdDocumentQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdDocumentResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdDomesticCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdFeesCalculationQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFeesCalculationResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFilingListQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFilingListResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFilingStatusQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFilingStatusResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdJuvenileCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdMessageReceiptMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdPaymentMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdPaymentReceiptMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdRecordDocketingCallbackMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdRecordDocketingMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdReviewFilingCallbackMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdServiceInformationQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdServiceInformationResponseMessage-4050
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 2 of 61
urnoasisnamestclegalxml-courtfilingschemaxsdServiceReceiptMessage-4050Abstract
This document defines the LegalXML Electronic Court Filing 40150 (ECF 540) specification which consists of a set of non-proprietary XML and Web services specifications along with clarifying explanations and amendments to those specifications that have been added for the purpose of promoting interoperability among electronic court filing vendors and systems ECF Version 40150 is a maintenance major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesto address several minor schema and definition issues identified by implementers of the ECF 40 specification
StatusThis document was last revised or approved by the members of OASIS LegalXML Electronic Court Filing TC on the above date The level of approval is also listed above Check the ldquoLatest versionrdquo location noted above for possible later revisions of this document Technical Committee members should send comments on this specification to the Technical Committeersquos email list Others should send comments to the Technical Committee by using the ldquoSend A Commentrdquo button on the Technical Committeersquos web page at httpwwwoasis-openorgcommitteeslegalxml-courtfilingFor information on whether any patents have been disclosed that may be essential to implementing this specification and any offers of patent licensing terms please refer to the Intellectual Property Rights section of the Technical Committee web page (httpwwwoasis-openorgcommitteeslegalxml-courtfilingiprphp)
Citation formatWhen referencing this specification the following citation format should be used
[ECF v40150]Electronic Court Filing Version 40150 23 May 2013 201 February 2012September 2013 OASIS Working Draft 01 Standard httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-oshtml Committee Specification Draft 03 Public Review Draft 03
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 3 of 61
NoticesCopyright copy OASIS Open 2013 All Rights ReservedAll capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the OASIS IPR Policy) The full Policy may be found at the OASIS websiteThis document and translations of it may be copied and furnished to others and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared copied published and distributed in whole or in part without restriction of any kind provided that the above copyright notice and this section are included on all such copies and derivative works However this document itself may not be modified in any way including by removing the copyright notice or references to OASIS except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights as set forth in the OASIS IPR Policy must be followed) or as required to translate it into languages other than EnglishThe limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assignsThis document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSEOASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specificationOASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification OASIS may include such claims on its website but disclaims any obligation to do soOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available neither does it represent that it has made any effort to identify any such rights Information on OASIS procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website Copies of claims of rights made available for publication and any assurances of licenses to be made available or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard can be obtained from the OASIS TC Administrator OASIS makes no representation that any information or list of intellectual property rights will at any time be complete or that any claims in such list are in fact Essential ClaimsThe name OASIS is a trademark of OASIS the owner and developer of this specification and should be used only to refer to the organization and its official outputs OASIS welcomes reference to and implementation and use of specifications while reserving the right to enforce its marks against misleading uses Please see httpwwwoasis-openorgpolicies-guidelinestrademarkhttpwwwoasis-openorgwhotrademarkphp for above guidance
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 4 of 61
Table of Contents1 Introduction 8
11 Scope 812 Relationship to Prior Specifications913 ECF Version 401 9
131 National Information Exchange Model (NIEM)10132 OASIS Universal Business Language10133 W3C XML-Signature Syntax and Processing11134 OASIS Reference Model for Service Oriented Architecture11135 OASIS Code List Representation (Genericode)11
14 Terms and Definitions 1115 Symbols and Abbreviations1216 Normative References1317 Non-Normative References14
2 ECF 40 Architecture 1621 Core vs Profiles 1622 Major Design Elements1623 Information Model 17
231 Messages 17232 Attachment 18233 Sample Message Streams18
24 Court Policy 21241 Human-Readable Court Policy21242 Machine-Readable Court Policy21243 Case-Type and Court Extensions22244 Court-Specific Code Lists22245 Court-Specific Constraint Schemas23
3 ECF 40 Process Model2431 The Filing-Preparation-to-Docketing Process Model2432 Business Rules 26
321 GetPolicy 26322 GetServiceInformation26323 GetFeesCalculation 26324 ReviewFiling 26325 ServeFiling 26326 RecordFiling 27327 NotifyDocketingComplete27328 NotifyFilingReviewComplete27329 GetFilingList 273210 GetFilingStatus 273211 GetCaseList 283212 GetCase 283213 GetDocument28
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 5 of 61
33 Message Business Rules28331 Identifiers 28332 Code Lists 29333 Message-Specific Business Rules31
34 Filing the Record on Appeal314 ECF 40 Schemas 34
41 ECF 40 Case Type Schemas3442 ECF 40 Common Schemas3443 ECF 40 Constraint and Subset Schemas3544 ECF 40 Message Schemas35
5 Service Interaction Profiles3751 Service Interaction Profile Requirements3752 Service Interaction Profile Approval and Revision Processes3853 Supported Service Interaction Profiles39
6 Document Signature Profiles4061 Document Signature Profile Requirements4062 Document Signature Profile Approval and Revision Processes4063 Supported Document Signature Profiles41
7 Conformance 42Appendix A (Informative) Release Notes43
A1 Availability 43A2 Package Structure 43A3 Recursive Structures43A4 Date and Time Formats 43A5 Known Errata 44
Appendix B (Informative) ECF 40 Development Approach and Artifacts45B1 Principles 45B2 Approach 45B3 ECF 40 Exchange Content Models45B4 Spreadsheet Models47
Appendix C (Informative) MDE Operations48C1 Filing Assembly MDE48
C11 Provided Operations48C12 Consumed Operations48
C2 Filing Review MDE 49C21 Provided Operations49C22 Consumed Operations49
C3 Court Record MDE 50C31 Provided Operations50C32 Consumed Operations50
C4 Legal Service MDE 50C41 Provided Operations 51C42 Consumed Operations 51
Appendix D (Informative) Example Instances52Appendix E (Informative) Ongoing Work Items54
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 6 of 61
Appendix F (Informative) Acknowledgments55Appendix G (Informative) Revision History56
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 7 of 61
1 IntroductionThis document is a specification developed by the OASIS LegalXML Electronic Court Filing Technical Committee It defines a technical architecture and a set of components operations and message structures for an electronic court filing system and sets forth rules governing its implementation
11 ScopeThis specification describes the technical architecture and the functional features needed to accomplish a successful electronic court filing system and defines both the normative (required) and non-normative (optional) business processes it supports The non-functional requirements associated with electronic filing transactions as well as the actions and services needed to accomplish the transactions such as network and security infrastructures are defined in related specifications namely Service interaction profile specifications that define communications infrastructures within which electronic filing
transactions can take place Document signature profile specifications that define mechanisms for stating or ensuring that a person signed a
particular document
This specification supports the following automated information exchanges Transmission of documents in electronic form from law firms and from other persons and organizations to a
court for entry (ldquoofficial filingrdquo) into the courtrsquos official case records Recording of documents in electronic form from members of the court and court administrators into the courtrsquos
official case records Transmission of data needed to complete (or demonstrate the previous completion of) financial transactions
involving filing fees or the payment of any other court fees fines and financial obligations Transmission of the metadata needed to initiate a new case record in a courtrsquos automated case management
system (CMS) when the document being transmitted is one that commences a new case in that court Transmission of the metadata needed to create an entry that records (indexes) a filed document in a courtrsquos
electronic listing of cases and their contents (variously called a ldquodocketrdquo or ldquoregister of actionsrdquo) Transmission of the metadata needed to update the information recorded about a case that is maintained in a
courtrsquos CMS Messages returned to the sender that confirm a courtrsquos receipt of the senderrsquos filing message Messages notifying the sender of events such as the entry of the document(s) submitted by the sender into the
court record (or an error message stating that the document[s] could not be accepted for filing and stating the reason[s] why)
Queries to the court seeking information about data and documents held within the courtrsquos official electronic records and the return of information in response to those queries
Queries from filers for the court rules and requirements for electronic filing Queries by filers seeking from the court record system the names and addresses of parties in a case who must
be served and whether by traditional or electronic means Transmission of copies of documents submitted for filing to the other parties in a case who are registered to
receive service electronically
In addition to filing of court case documents this specification supports ldquosecondary servicerdquo ndash the delivery of copies of filed documents to persons who have already been made parties to a case This specification does NOT support ldquoprimary servicerdquo which entails the service of summonses subpoenas warrants and other documents that
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 8 of 61
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
SECRETARY Additional artifacts
This prose specification is one component of a Work Product which also includes XML schemas
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosxsd XML sample messages
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosxml Model
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosmodel Genericode code lists
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosgc Related work
This specification replaces or supersedes OASIS LegalXML Electronic Court Filing Version 30 15 November 2005
httpdocsoasis-openorglegalxml-courtfilingspecsecfv30 OASIS Electronic Court Filing Version 40 21 September 2008
httpdocsoasis-openorglegalxml-courtfilingspecsecfv40ecf-v40-spec OASIS Electronic Court Filing Version 401 23 May 2013
httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specThis specification is related to National Information Exchange Model 320
Declared XML namespacesurnoasisnamestclegalxml-courtfilingschemaxsdAppInfo-4050urnoasisnamestclegalxml-courtfilingschemaxsdAppellateCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdBankruptcyCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdCaseListQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCaseListResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCaseQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCaseResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCitationCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdCivilCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdCommonTypes-4050urnoasisnamestclegalxml-courtfilingschemaxsdCoreFilingMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCourtPolicyQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCourtPolicyResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdCriminalCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdDocumentQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdDocumentResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdDomesticCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdFeesCalculationQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFeesCalculationResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFilingListQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFilingListResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFilingStatusQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdFilingStatusResponseMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdJuvenileCase-4050urnoasisnamestclegalxml-courtfilingschemaxsdMessageReceiptMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdPaymentMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdPaymentReceiptMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdRecordDocketingCallbackMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdRecordDocketingMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdReviewFilingCallbackMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdServiceInformationQueryMessage-4050urnoasisnamestclegalxml-courtfilingschemaxsdServiceInformationResponseMessage-4050
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 2 of 61
urnoasisnamestclegalxml-courtfilingschemaxsdServiceReceiptMessage-4050Abstract
This document defines the LegalXML Electronic Court Filing 40150 (ECF 540) specification which consists of a set of non-proprietary XML and Web services specifications along with clarifying explanations and amendments to those specifications that have been added for the purpose of promoting interoperability among electronic court filing vendors and systems ECF Version 40150 is a maintenance major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesto address several minor schema and definition issues identified by implementers of the ECF 40 specification
StatusThis document was last revised or approved by the members of OASIS LegalXML Electronic Court Filing TC on the above date The level of approval is also listed above Check the ldquoLatest versionrdquo location noted above for possible later revisions of this document Technical Committee members should send comments on this specification to the Technical Committeersquos email list Others should send comments to the Technical Committee by using the ldquoSend A Commentrdquo button on the Technical Committeersquos web page at httpwwwoasis-openorgcommitteeslegalxml-courtfilingFor information on whether any patents have been disclosed that may be essential to implementing this specification and any offers of patent licensing terms please refer to the Intellectual Property Rights section of the Technical Committee web page (httpwwwoasis-openorgcommitteeslegalxml-courtfilingiprphp)
Citation formatWhen referencing this specification the following citation format should be used
[ECF v40150]Electronic Court Filing Version 40150 23 May 2013 201 February 2012September 2013 OASIS Working Draft 01 Standard httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-oshtml Committee Specification Draft 03 Public Review Draft 03
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 3 of 61
NoticesCopyright copy OASIS Open 2013 All Rights ReservedAll capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the OASIS IPR Policy) The full Policy may be found at the OASIS websiteThis document and translations of it may be copied and furnished to others and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared copied published and distributed in whole or in part without restriction of any kind provided that the above copyright notice and this section are included on all such copies and derivative works However this document itself may not be modified in any way including by removing the copyright notice or references to OASIS except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights as set forth in the OASIS IPR Policy must be followed) or as required to translate it into languages other than EnglishThe limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assignsThis document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSEOASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specificationOASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification OASIS may include such claims on its website but disclaims any obligation to do soOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available neither does it represent that it has made any effort to identify any such rights Information on OASIS procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website Copies of claims of rights made available for publication and any assurances of licenses to be made available or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard can be obtained from the OASIS TC Administrator OASIS makes no representation that any information or list of intellectual property rights will at any time be complete or that any claims in such list are in fact Essential ClaimsThe name OASIS is a trademark of OASIS the owner and developer of this specification and should be used only to refer to the organization and its official outputs OASIS welcomes reference to and implementation and use of specifications while reserving the right to enforce its marks against misleading uses Please see httpwwwoasis-openorgpolicies-guidelinestrademarkhttpwwwoasis-openorgwhotrademarkphp for above guidance
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 4 of 61
Table of Contents1 Introduction 8
11 Scope 812 Relationship to Prior Specifications913 ECF Version 401 9
131 National Information Exchange Model (NIEM)10132 OASIS Universal Business Language10133 W3C XML-Signature Syntax and Processing11134 OASIS Reference Model for Service Oriented Architecture11135 OASIS Code List Representation (Genericode)11
14 Terms and Definitions 1115 Symbols and Abbreviations1216 Normative References1317 Non-Normative References14
2 ECF 40 Architecture 1621 Core vs Profiles 1622 Major Design Elements1623 Information Model 17
231 Messages 17232 Attachment 18233 Sample Message Streams18
24 Court Policy 21241 Human-Readable Court Policy21242 Machine-Readable Court Policy21243 Case-Type and Court Extensions22244 Court-Specific Code Lists22245 Court-Specific Constraint Schemas23
3 ECF 40 Process Model2431 The Filing-Preparation-to-Docketing Process Model2432 Business Rules 26
321 GetPolicy 26322 GetServiceInformation26323 GetFeesCalculation 26324 ReviewFiling 26325 ServeFiling 26326 RecordFiling 27327 NotifyDocketingComplete27328 NotifyFilingReviewComplete27329 GetFilingList 273210 GetFilingStatus 273211 GetCaseList 283212 GetCase 283213 GetDocument28
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 5 of 61
33 Message Business Rules28331 Identifiers 28332 Code Lists 29333 Message-Specific Business Rules31
34 Filing the Record on Appeal314 ECF 40 Schemas 34
41 ECF 40 Case Type Schemas3442 ECF 40 Common Schemas3443 ECF 40 Constraint and Subset Schemas3544 ECF 40 Message Schemas35
5 Service Interaction Profiles3751 Service Interaction Profile Requirements3752 Service Interaction Profile Approval and Revision Processes3853 Supported Service Interaction Profiles39
6 Document Signature Profiles4061 Document Signature Profile Requirements4062 Document Signature Profile Approval and Revision Processes4063 Supported Document Signature Profiles41
7 Conformance 42Appendix A (Informative) Release Notes43
A1 Availability 43A2 Package Structure 43A3 Recursive Structures43A4 Date and Time Formats 43A5 Known Errata 44
Appendix B (Informative) ECF 40 Development Approach and Artifacts45B1 Principles 45B2 Approach 45B3 ECF 40 Exchange Content Models45B4 Spreadsheet Models47
Appendix C (Informative) MDE Operations48C1 Filing Assembly MDE48
C11 Provided Operations48C12 Consumed Operations48
C2 Filing Review MDE 49C21 Provided Operations49C22 Consumed Operations49
C3 Court Record MDE 50C31 Provided Operations50C32 Consumed Operations50
C4 Legal Service MDE 50C41 Provided Operations 51C42 Consumed Operations 51
Appendix D (Informative) Example Instances52Appendix E (Informative) Ongoing Work Items54
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 6 of 61
Appendix F (Informative) Acknowledgments55Appendix G (Informative) Revision History56
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 7 of 61
1 IntroductionThis document is a specification developed by the OASIS LegalXML Electronic Court Filing Technical Committee It defines a technical architecture and a set of components operations and message structures for an electronic court filing system and sets forth rules governing its implementation
11 ScopeThis specification describes the technical architecture and the functional features needed to accomplish a successful electronic court filing system and defines both the normative (required) and non-normative (optional) business processes it supports The non-functional requirements associated with electronic filing transactions as well as the actions and services needed to accomplish the transactions such as network and security infrastructures are defined in related specifications namely Service interaction profile specifications that define communications infrastructures within which electronic filing
transactions can take place Document signature profile specifications that define mechanisms for stating or ensuring that a person signed a
particular document
This specification supports the following automated information exchanges Transmission of documents in electronic form from law firms and from other persons and organizations to a
court for entry (ldquoofficial filingrdquo) into the courtrsquos official case records Recording of documents in electronic form from members of the court and court administrators into the courtrsquos
official case records Transmission of data needed to complete (or demonstrate the previous completion of) financial transactions
involving filing fees or the payment of any other court fees fines and financial obligations Transmission of the metadata needed to initiate a new case record in a courtrsquos automated case management
system (CMS) when the document being transmitted is one that commences a new case in that court Transmission of the metadata needed to create an entry that records (indexes) a filed document in a courtrsquos
electronic listing of cases and their contents (variously called a ldquodocketrdquo or ldquoregister of actionsrdquo) Transmission of the metadata needed to update the information recorded about a case that is maintained in a
courtrsquos CMS Messages returned to the sender that confirm a courtrsquos receipt of the senderrsquos filing message Messages notifying the sender of events such as the entry of the document(s) submitted by the sender into the
court record (or an error message stating that the document[s] could not be accepted for filing and stating the reason[s] why)
Queries to the court seeking information about data and documents held within the courtrsquos official electronic records and the return of information in response to those queries
Queries from filers for the court rules and requirements for electronic filing Queries by filers seeking from the court record system the names and addresses of parties in a case who must
be served and whether by traditional or electronic means Transmission of copies of documents submitted for filing to the other parties in a case who are registered to
receive service electronically
In addition to filing of court case documents this specification supports ldquosecondary servicerdquo ndash the delivery of copies of filed documents to persons who have already been made parties to a case This specification does NOT support ldquoprimary servicerdquo which entails the service of summonses subpoenas warrants and other documents that
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 8 of 61
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
urnoasisnamestclegalxml-courtfilingschemaxsdServiceReceiptMessage-4050Abstract
This document defines the LegalXML Electronic Court Filing 40150 (ECF 540) specification which consists of a set of non-proprietary XML and Web services specifications along with clarifying explanations and amendments to those specifications that have been added for the purpose of promoting interoperability among electronic court filing vendors and systems ECF Version 40150 is a maintenance major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesto address several minor schema and definition issues identified by implementers of the ECF 40 specification
StatusThis document was last revised or approved by the members of OASIS LegalXML Electronic Court Filing TC on the above date The level of approval is also listed above Check the ldquoLatest versionrdquo location noted above for possible later revisions of this document Technical Committee members should send comments on this specification to the Technical Committeersquos email list Others should send comments to the Technical Committee by using the ldquoSend A Commentrdquo button on the Technical Committeersquos web page at httpwwwoasis-openorgcommitteeslegalxml-courtfilingFor information on whether any patents have been disclosed that may be essential to implementing this specification and any offers of patent licensing terms please refer to the Intellectual Property Rights section of the Technical Committee web page (httpwwwoasis-openorgcommitteeslegalxml-courtfilingiprphp)
Citation formatWhen referencing this specification the following citation format should be used
[ECF v40150]Electronic Court Filing Version 40150 23 May 2013 201 February 2012September 2013 OASIS Working Draft 01 Standard httpdocsoasis-openorglegalxml-courtfilingspecsecfv401ecf-v401-specosecf-v401-spec-oshtml Committee Specification Draft 03 Public Review Draft 03
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 3 of 61
NoticesCopyright copy OASIS Open 2013 All Rights ReservedAll capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the OASIS IPR Policy) The full Policy may be found at the OASIS websiteThis document and translations of it may be copied and furnished to others and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared copied published and distributed in whole or in part without restriction of any kind provided that the above copyright notice and this section are included on all such copies and derivative works However this document itself may not be modified in any way including by removing the copyright notice or references to OASIS except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights as set forth in the OASIS IPR Policy must be followed) or as required to translate it into languages other than EnglishThe limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assignsThis document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSEOASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specificationOASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification OASIS may include such claims on its website but disclaims any obligation to do soOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available neither does it represent that it has made any effort to identify any such rights Information on OASIS procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website Copies of claims of rights made available for publication and any assurances of licenses to be made available or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard can be obtained from the OASIS TC Administrator OASIS makes no representation that any information or list of intellectual property rights will at any time be complete or that any claims in such list are in fact Essential ClaimsThe name OASIS is a trademark of OASIS the owner and developer of this specification and should be used only to refer to the organization and its official outputs OASIS welcomes reference to and implementation and use of specifications while reserving the right to enforce its marks against misleading uses Please see httpwwwoasis-openorgpolicies-guidelinestrademarkhttpwwwoasis-openorgwhotrademarkphp for above guidance
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 4 of 61
Table of Contents1 Introduction 8
11 Scope 812 Relationship to Prior Specifications913 ECF Version 401 9
131 National Information Exchange Model (NIEM)10132 OASIS Universal Business Language10133 W3C XML-Signature Syntax and Processing11134 OASIS Reference Model for Service Oriented Architecture11135 OASIS Code List Representation (Genericode)11
14 Terms and Definitions 1115 Symbols and Abbreviations1216 Normative References1317 Non-Normative References14
2 ECF 40 Architecture 1621 Core vs Profiles 1622 Major Design Elements1623 Information Model 17
231 Messages 17232 Attachment 18233 Sample Message Streams18
24 Court Policy 21241 Human-Readable Court Policy21242 Machine-Readable Court Policy21243 Case-Type and Court Extensions22244 Court-Specific Code Lists22245 Court-Specific Constraint Schemas23
3 ECF 40 Process Model2431 The Filing-Preparation-to-Docketing Process Model2432 Business Rules 26
321 GetPolicy 26322 GetServiceInformation26323 GetFeesCalculation 26324 ReviewFiling 26325 ServeFiling 26326 RecordFiling 27327 NotifyDocketingComplete27328 NotifyFilingReviewComplete27329 GetFilingList 273210 GetFilingStatus 273211 GetCaseList 283212 GetCase 283213 GetDocument28
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 5 of 61
33 Message Business Rules28331 Identifiers 28332 Code Lists 29333 Message-Specific Business Rules31
34 Filing the Record on Appeal314 ECF 40 Schemas 34
41 ECF 40 Case Type Schemas3442 ECF 40 Common Schemas3443 ECF 40 Constraint and Subset Schemas3544 ECF 40 Message Schemas35
5 Service Interaction Profiles3751 Service Interaction Profile Requirements3752 Service Interaction Profile Approval and Revision Processes3853 Supported Service Interaction Profiles39
6 Document Signature Profiles4061 Document Signature Profile Requirements4062 Document Signature Profile Approval and Revision Processes4063 Supported Document Signature Profiles41
7 Conformance 42Appendix A (Informative) Release Notes43
A1 Availability 43A2 Package Structure 43A3 Recursive Structures43A4 Date and Time Formats 43A5 Known Errata 44
Appendix B (Informative) ECF 40 Development Approach and Artifacts45B1 Principles 45B2 Approach 45B3 ECF 40 Exchange Content Models45B4 Spreadsheet Models47
Appendix C (Informative) MDE Operations48C1 Filing Assembly MDE48
C11 Provided Operations48C12 Consumed Operations48
C2 Filing Review MDE 49C21 Provided Operations49C22 Consumed Operations49
C3 Court Record MDE 50C31 Provided Operations50C32 Consumed Operations50
C4 Legal Service MDE 50C41 Provided Operations 51C42 Consumed Operations 51
Appendix D (Informative) Example Instances52Appendix E (Informative) Ongoing Work Items54
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 6 of 61
Appendix F (Informative) Acknowledgments55Appendix G (Informative) Revision History56
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 7 of 61
1 IntroductionThis document is a specification developed by the OASIS LegalXML Electronic Court Filing Technical Committee It defines a technical architecture and a set of components operations and message structures for an electronic court filing system and sets forth rules governing its implementation
11 ScopeThis specification describes the technical architecture and the functional features needed to accomplish a successful electronic court filing system and defines both the normative (required) and non-normative (optional) business processes it supports The non-functional requirements associated with electronic filing transactions as well as the actions and services needed to accomplish the transactions such as network and security infrastructures are defined in related specifications namely Service interaction profile specifications that define communications infrastructures within which electronic filing
transactions can take place Document signature profile specifications that define mechanisms for stating or ensuring that a person signed a
particular document
This specification supports the following automated information exchanges Transmission of documents in electronic form from law firms and from other persons and organizations to a
court for entry (ldquoofficial filingrdquo) into the courtrsquos official case records Recording of documents in electronic form from members of the court and court administrators into the courtrsquos
official case records Transmission of data needed to complete (or demonstrate the previous completion of) financial transactions
involving filing fees or the payment of any other court fees fines and financial obligations Transmission of the metadata needed to initiate a new case record in a courtrsquos automated case management
system (CMS) when the document being transmitted is one that commences a new case in that court Transmission of the metadata needed to create an entry that records (indexes) a filed document in a courtrsquos
electronic listing of cases and their contents (variously called a ldquodocketrdquo or ldquoregister of actionsrdquo) Transmission of the metadata needed to update the information recorded about a case that is maintained in a
courtrsquos CMS Messages returned to the sender that confirm a courtrsquos receipt of the senderrsquos filing message Messages notifying the sender of events such as the entry of the document(s) submitted by the sender into the
court record (or an error message stating that the document[s] could not be accepted for filing and stating the reason[s] why)
Queries to the court seeking information about data and documents held within the courtrsquos official electronic records and the return of information in response to those queries
Queries from filers for the court rules and requirements for electronic filing Queries by filers seeking from the court record system the names and addresses of parties in a case who must
be served and whether by traditional or electronic means Transmission of copies of documents submitted for filing to the other parties in a case who are registered to
receive service electronically
In addition to filing of court case documents this specification supports ldquosecondary servicerdquo ndash the delivery of copies of filed documents to persons who have already been made parties to a case This specification does NOT support ldquoprimary servicerdquo which entails the service of summonses subpoenas warrants and other documents that
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 8 of 61
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
NoticesCopyright copy OASIS Open 2013 All Rights ReservedAll capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the OASIS IPR Policy) The full Policy may be found at the OASIS websiteThis document and translations of it may be copied and furnished to others and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared copied published and distributed in whole or in part without restriction of any kind provided that the above copyright notice and this section are included on all such copies and derivative works However this document itself may not be modified in any way including by removing the copyright notice or references to OASIS except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights as set forth in the OASIS IPR Policy must be followed) or as required to translate it into languages other than EnglishThe limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assignsThis document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSEOASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specificationOASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification OASIS may include such claims on its website but disclaims any obligation to do soOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available neither does it represent that it has made any effort to identify any such rights Information on OASIS procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website Copies of claims of rights made available for publication and any assurances of licenses to be made available or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard can be obtained from the OASIS TC Administrator OASIS makes no representation that any information or list of intellectual property rights will at any time be complete or that any claims in such list are in fact Essential ClaimsThe name OASIS is a trademark of OASIS the owner and developer of this specification and should be used only to refer to the organization and its official outputs OASIS welcomes reference to and implementation and use of specifications while reserving the right to enforce its marks against misleading uses Please see httpwwwoasis-openorgpolicies-guidelinestrademarkhttpwwwoasis-openorgwhotrademarkphp for above guidance
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 4 of 61
Table of Contents1 Introduction 8
11 Scope 812 Relationship to Prior Specifications913 ECF Version 401 9
131 National Information Exchange Model (NIEM)10132 OASIS Universal Business Language10133 W3C XML-Signature Syntax and Processing11134 OASIS Reference Model for Service Oriented Architecture11135 OASIS Code List Representation (Genericode)11
14 Terms and Definitions 1115 Symbols and Abbreviations1216 Normative References1317 Non-Normative References14
2 ECF 40 Architecture 1621 Core vs Profiles 1622 Major Design Elements1623 Information Model 17
231 Messages 17232 Attachment 18233 Sample Message Streams18
24 Court Policy 21241 Human-Readable Court Policy21242 Machine-Readable Court Policy21243 Case-Type and Court Extensions22244 Court-Specific Code Lists22245 Court-Specific Constraint Schemas23
3 ECF 40 Process Model2431 The Filing-Preparation-to-Docketing Process Model2432 Business Rules 26
321 GetPolicy 26322 GetServiceInformation26323 GetFeesCalculation 26324 ReviewFiling 26325 ServeFiling 26326 RecordFiling 27327 NotifyDocketingComplete27328 NotifyFilingReviewComplete27329 GetFilingList 273210 GetFilingStatus 273211 GetCaseList 283212 GetCase 283213 GetDocument28
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 5 of 61
33 Message Business Rules28331 Identifiers 28332 Code Lists 29333 Message-Specific Business Rules31
34 Filing the Record on Appeal314 ECF 40 Schemas 34
41 ECF 40 Case Type Schemas3442 ECF 40 Common Schemas3443 ECF 40 Constraint and Subset Schemas3544 ECF 40 Message Schemas35
5 Service Interaction Profiles3751 Service Interaction Profile Requirements3752 Service Interaction Profile Approval and Revision Processes3853 Supported Service Interaction Profiles39
6 Document Signature Profiles4061 Document Signature Profile Requirements4062 Document Signature Profile Approval and Revision Processes4063 Supported Document Signature Profiles41
7 Conformance 42Appendix A (Informative) Release Notes43
A1 Availability 43A2 Package Structure 43A3 Recursive Structures43A4 Date and Time Formats 43A5 Known Errata 44
Appendix B (Informative) ECF 40 Development Approach and Artifacts45B1 Principles 45B2 Approach 45B3 ECF 40 Exchange Content Models45B4 Spreadsheet Models47
Appendix C (Informative) MDE Operations48C1 Filing Assembly MDE48
C11 Provided Operations48C12 Consumed Operations48
C2 Filing Review MDE 49C21 Provided Operations49C22 Consumed Operations49
C3 Court Record MDE 50C31 Provided Operations50C32 Consumed Operations50
C4 Legal Service MDE 50C41 Provided Operations 51C42 Consumed Operations 51
Appendix D (Informative) Example Instances52Appendix E (Informative) Ongoing Work Items54
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 6 of 61
Appendix F (Informative) Acknowledgments55Appendix G (Informative) Revision History56
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 7 of 61
1 IntroductionThis document is a specification developed by the OASIS LegalXML Electronic Court Filing Technical Committee It defines a technical architecture and a set of components operations and message structures for an electronic court filing system and sets forth rules governing its implementation
11 ScopeThis specification describes the technical architecture and the functional features needed to accomplish a successful electronic court filing system and defines both the normative (required) and non-normative (optional) business processes it supports The non-functional requirements associated with electronic filing transactions as well as the actions and services needed to accomplish the transactions such as network and security infrastructures are defined in related specifications namely Service interaction profile specifications that define communications infrastructures within which electronic filing
transactions can take place Document signature profile specifications that define mechanisms for stating or ensuring that a person signed a
particular document
This specification supports the following automated information exchanges Transmission of documents in electronic form from law firms and from other persons and organizations to a
court for entry (ldquoofficial filingrdquo) into the courtrsquos official case records Recording of documents in electronic form from members of the court and court administrators into the courtrsquos
official case records Transmission of data needed to complete (or demonstrate the previous completion of) financial transactions
involving filing fees or the payment of any other court fees fines and financial obligations Transmission of the metadata needed to initiate a new case record in a courtrsquos automated case management
system (CMS) when the document being transmitted is one that commences a new case in that court Transmission of the metadata needed to create an entry that records (indexes) a filed document in a courtrsquos
electronic listing of cases and their contents (variously called a ldquodocketrdquo or ldquoregister of actionsrdquo) Transmission of the metadata needed to update the information recorded about a case that is maintained in a
courtrsquos CMS Messages returned to the sender that confirm a courtrsquos receipt of the senderrsquos filing message Messages notifying the sender of events such as the entry of the document(s) submitted by the sender into the
court record (or an error message stating that the document[s] could not be accepted for filing and stating the reason[s] why)
Queries to the court seeking information about data and documents held within the courtrsquos official electronic records and the return of information in response to those queries
Queries from filers for the court rules and requirements for electronic filing Queries by filers seeking from the court record system the names and addresses of parties in a case who must
be served and whether by traditional or electronic means Transmission of copies of documents submitted for filing to the other parties in a case who are registered to
receive service electronically
In addition to filing of court case documents this specification supports ldquosecondary servicerdquo ndash the delivery of copies of filed documents to persons who have already been made parties to a case This specification does NOT support ldquoprimary servicerdquo which entails the service of summonses subpoenas warrants and other documents that
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 8 of 61
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Table of Contents1 Introduction 8
11 Scope 812 Relationship to Prior Specifications913 ECF Version 401 9
131 National Information Exchange Model (NIEM)10132 OASIS Universal Business Language10133 W3C XML-Signature Syntax and Processing11134 OASIS Reference Model for Service Oriented Architecture11135 OASIS Code List Representation (Genericode)11
14 Terms and Definitions 1115 Symbols and Abbreviations1216 Normative References1317 Non-Normative References14
2 ECF 40 Architecture 1621 Core vs Profiles 1622 Major Design Elements1623 Information Model 17
231 Messages 17232 Attachment 18233 Sample Message Streams18
24 Court Policy 21241 Human-Readable Court Policy21242 Machine-Readable Court Policy21243 Case-Type and Court Extensions22244 Court-Specific Code Lists22245 Court-Specific Constraint Schemas23
3 ECF 40 Process Model2431 The Filing-Preparation-to-Docketing Process Model2432 Business Rules 26
321 GetPolicy 26322 GetServiceInformation26323 GetFeesCalculation 26324 ReviewFiling 26325 ServeFiling 26326 RecordFiling 27327 NotifyDocketingComplete27328 NotifyFilingReviewComplete27329 GetFilingList 273210 GetFilingStatus 273211 GetCaseList 283212 GetCase 283213 GetDocument28
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 5 of 61
33 Message Business Rules28331 Identifiers 28332 Code Lists 29333 Message-Specific Business Rules31
34 Filing the Record on Appeal314 ECF 40 Schemas 34
41 ECF 40 Case Type Schemas3442 ECF 40 Common Schemas3443 ECF 40 Constraint and Subset Schemas3544 ECF 40 Message Schemas35
5 Service Interaction Profiles3751 Service Interaction Profile Requirements3752 Service Interaction Profile Approval and Revision Processes3853 Supported Service Interaction Profiles39
6 Document Signature Profiles4061 Document Signature Profile Requirements4062 Document Signature Profile Approval and Revision Processes4063 Supported Document Signature Profiles41
7 Conformance 42Appendix A (Informative) Release Notes43
A1 Availability 43A2 Package Structure 43A3 Recursive Structures43A4 Date and Time Formats 43A5 Known Errata 44
Appendix B (Informative) ECF 40 Development Approach and Artifacts45B1 Principles 45B2 Approach 45B3 ECF 40 Exchange Content Models45B4 Spreadsheet Models47
Appendix C (Informative) MDE Operations48C1 Filing Assembly MDE48
C11 Provided Operations48C12 Consumed Operations48
C2 Filing Review MDE 49C21 Provided Operations49C22 Consumed Operations49
C3 Court Record MDE 50C31 Provided Operations50C32 Consumed Operations50
C4 Legal Service MDE 50C41 Provided Operations 51C42 Consumed Operations 51
Appendix D (Informative) Example Instances52Appendix E (Informative) Ongoing Work Items54
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 6 of 61
Appendix F (Informative) Acknowledgments55Appendix G (Informative) Revision History56
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 7 of 61
1 IntroductionThis document is a specification developed by the OASIS LegalXML Electronic Court Filing Technical Committee It defines a technical architecture and a set of components operations and message structures for an electronic court filing system and sets forth rules governing its implementation
11 ScopeThis specification describes the technical architecture and the functional features needed to accomplish a successful electronic court filing system and defines both the normative (required) and non-normative (optional) business processes it supports The non-functional requirements associated with electronic filing transactions as well as the actions and services needed to accomplish the transactions such as network and security infrastructures are defined in related specifications namely Service interaction profile specifications that define communications infrastructures within which electronic filing
transactions can take place Document signature profile specifications that define mechanisms for stating or ensuring that a person signed a
particular document
This specification supports the following automated information exchanges Transmission of documents in electronic form from law firms and from other persons and organizations to a
court for entry (ldquoofficial filingrdquo) into the courtrsquos official case records Recording of documents in electronic form from members of the court and court administrators into the courtrsquos
official case records Transmission of data needed to complete (or demonstrate the previous completion of) financial transactions
involving filing fees or the payment of any other court fees fines and financial obligations Transmission of the metadata needed to initiate a new case record in a courtrsquos automated case management
system (CMS) when the document being transmitted is one that commences a new case in that court Transmission of the metadata needed to create an entry that records (indexes) a filed document in a courtrsquos
electronic listing of cases and their contents (variously called a ldquodocketrdquo or ldquoregister of actionsrdquo) Transmission of the metadata needed to update the information recorded about a case that is maintained in a
courtrsquos CMS Messages returned to the sender that confirm a courtrsquos receipt of the senderrsquos filing message Messages notifying the sender of events such as the entry of the document(s) submitted by the sender into the
court record (or an error message stating that the document[s] could not be accepted for filing and stating the reason[s] why)
Queries to the court seeking information about data and documents held within the courtrsquos official electronic records and the return of information in response to those queries
Queries from filers for the court rules and requirements for electronic filing Queries by filers seeking from the court record system the names and addresses of parties in a case who must
be served and whether by traditional or electronic means Transmission of copies of documents submitted for filing to the other parties in a case who are registered to
receive service electronically
In addition to filing of court case documents this specification supports ldquosecondary servicerdquo ndash the delivery of copies of filed documents to persons who have already been made parties to a case This specification does NOT support ldquoprimary servicerdquo which entails the service of summonses subpoenas warrants and other documents that
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 8 of 61
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
33 Message Business Rules28331 Identifiers 28332 Code Lists 29333 Message-Specific Business Rules31
34 Filing the Record on Appeal314 ECF 40 Schemas 34
41 ECF 40 Case Type Schemas3442 ECF 40 Common Schemas3443 ECF 40 Constraint and Subset Schemas3544 ECF 40 Message Schemas35
5 Service Interaction Profiles3751 Service Interaction Profile Requirements3752 Service Interaction Profile Approval and Revision Processes3853 Supported Service Interaction Profiles39
6 Document Signature Profiles4061 Document Signature Profile Requirements4062 Document Signature Profile Approval and Revision Processes4063 Supported Document Signature Profiles41
7 Conformance 42Appendix A (Informative) Release Notes43
A1 Availability 43A2 Package Structure 43A3 Recursive Structures43A4 Date and Time Formats 43A5 Known Errata 44
Appendix B (Informative) ECF 40 Development Approach and Artifacts45B1 Principles 45B2 Approach 45B3 ECF 40 Exchange Content Models45B4 Spreadsheet Models47
Appendix C (Informative) MDE Operations48C1 Filing Assembly MDE48
C11 Provided Operations48C12 Consumed Operations48
C2 Filing Review MDE 49C21 Provided Operations49C22 Consumed Operations49
C3 Court Record MDE 50C31 Provided Operations50C32 Consumed Operations50
C4 Legal Service MDE 50C41 Provided Operations 51C42 Consumed Operations 51
Appendix D (Informative) Example Instances52Appendix E (Informative) Ongoing Work Items54
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 6 of 61
Appendix F (Informative) Acknowledgments55Appendix G (Informative) Revision History56
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 7 of 61
1 IntroductionThis document is a specification developed by the OASIS LegalXML Electronic Court Filing Technical Committee It defines a technical architecture and a set of components operations and message structures for an electronic court filing system and sets forth rules governing its implementation
11 ScopeThis specification describes the technical architecture and the functional features needed to accomplish a successful electronic court filing system and defines both the normative (required) and non-normative (optional) business processes it supports The non-functional requirements associated with electronic filing transactions as well as the actions and services needed to accomplish the transactions such as network and security infrastructures are defined in related specifications namely Service interaction profile specifications that define communications infrastructures within which electronic filing
transactions can take place Document signature profile specifications that define mechanisms for stating or ensuring that a person signed a
particular document
This specification supports the following automated information exchanges Transmission of documents in electronic form from law firms and from other persons and organizations to a
court for entry (ldquoofficial filingrdquo) into the courtrsquos official case records Recording of documents in electronic form from members of the court and court administrators into the courtrsquos
official case records Transmission of data needed to complete (or demonstrate the previous completion of) financial transactions
involving filing fees or the payment of any other court fees fines and financial obligations Transmission of the metadata needed to initiate a new case record in a courtrsquos automated case management
system (CMS) when the document being transmitted is one that commences a new case in that court Transmission of the metadata needed to create an entry that records (indexes) a filed document in a courtrsquos
electronic listing of cases and their contents (variously called a ldquodocketrdquo or ldquoregister of actionsrdquo) Transmission of the metadata needed to update the information recorded about a case that is maintained in a
courtrsquos CMS Messages returned to the sender that confirm a courtrsquos receipt of the senderrsquos filing message Messages notifying the sender of events such as the entry of the document(s) submitted by the sender into the
court record (or an error message stating that the document[s] could not be accepted for filing and stating the reason[s] why)
Queries to the court seeking information about data and documents held within the courtrsquos official electronic records and the return of information in response to those queries
Queries from filers for the court rules and requirements for electronic filing Queries by filers seeking from the court record system the names and addresses of parties in a case who must
be served and whether by traditional or electronic means Transmission of copies of documents submitted for filing to the other parties in a case who are registered to
receive service electronically
In addition to filing of court case documents this specification supports ldquosecondary servicerdquo ndash the delivery of copies of filed documents to persons who have already been made parties to a case This specification does NOT support ldquoprimary servicerdquo which entails the service of summonses subpoenas warrants and other documents that
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 8 of 61
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Appendix F (Informative) Acknowledgments55Appendix G (Informative) Revision History56
ecf-spec-v401-spec-os 23 May 2013csprd03 21 February 2012Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 7 of 61
1 IntroductionThis document is a specification developed by the OASIS LegalXML Electronic Court Filing Technical Committee It defines a technical architecture and a set of components operations and message structures for an electronic court filing system and sets forth rules governing its implementation
11 ScopeThis specification describes the technical architecture and the functional features needed to accomplish a successful electronic court filing system and defines both the normative (required) and non-normative (optional) business processes it supports The non-functional requirements associated with electronic filing transactions as well as the actions and services needed to accomplish the transactions such as network and security infrastructures are defined in related specifications namely Service interaction profile specifications that define communications infrastructures within which electronic filing
transactions can take place Document signature profile specifications that define mechanisms for stating or ensuring that a person signed a
particular document
This specification supports the following automated information exchanges Transmission of documents in electronic form from law firms and from other persons and organizations to a
court for entry (ldquoofficial filingrdquo) into the courtrsquos official case records Recording of documents in electronic form from members of the court and court administrators into the courtrsquos
official case records Transmission of data needed to complete (or demonstrate the previous completion of) financial transactions
involving filing fees or the payment of any other court fees fines and financial obligations Transmission of the metadata needed to initiate a new case record in a courtrsquos automated case management
system (CMS) when the document being transmitted is one that commences a new case in that court Transmission of the metadata needed to create an entry that records (indexes) a filed document in a courtrsquos
electronic listing of cases and their contents (variously called a ldquodocketrdquo or ldquoregister of actionsrdquo) Transmission of the metadata needed to update the information recorded about a case that is maintained in a
courtrsquos CMS Messages returned to the sender that confirm a courtrsquos receipt of the senderrsquos filing message Messages notifying the sender of events such as the entry of the document(s) submitted by the sender into the
court record (or an error message stating that the document[s] could not be accepted for filing and stating the reason[s] why)
Queries to the court seeking information about data and documents held within the courtrsquos official electronic records and the return of information in response to those queries
Queries from filers for the court rules and requirements for electronic filing Queries by filers seeking from the court record system the names and addresses of parties in a case who must
be served and whether by traditional or electronic means Transmission of copies of documents submitted for filing to the other parties in a case who are registered to
receive service electronically
In addition to filing of court case documents this specification supports ldquosecondary servicerdquo ndash the delivery of copies of filed documents to persons who have already been made parties to a case This specification does NOT support ldquoprimary servicerdquo which entails the service of summonses subpoenas warrants and other documents that
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 8 of 61
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
1 IntroductionThis document is a specification developed by the OASIS LegalXML Electronic Court Filing Technical Committee It defines a technical architecture and a set of components operations and message structures for an electronic court filing system and sets forth rules governing its implementation
11 ScopeThis specification describes the technical architecture and the functional features needed to accomplish a successful electronic court filing system and defines both the normative (required) and non-normative (optional) business processes it supports The non-functional requirements associated with electronic filing transactions as well as the actions and services needed to accomplish the transactions such as network and security infrastructures are defined in related specifications namely Service interaction profile specifications that define communications infrastructures within which electronic filing
transactions can take place Document signature profile specifications that define mechanisms for stating or ensuring that a person signed a
particular document
This specification supports the following automated information exchanges Transmission of documents in electronic form from law firms and from other persons and organizations to a
court for entry (ldquoofficial filingrdquo) into the courtrsquos official case records Recording of documents in electronic form from members of the court and court administrators into the courtrsquos
official case records Transmission of data needed to complete (or demonstrate the previous completion of) financial transactions
involving filing fees or the payment of any other court fees fines and financial obligations Transmission of the metadata needed to initiate a new case record in a courtrsquos automated case management
system (CMS) when the document being transmitted is one that commences a new case in that court Transmission of the metadata needed to create an entry that records (indexes) a filed document in a courtrsquos
electronic listing of cases and their contents (variously called a ldquodocketrdquo or ldquoregister of actionsrdquo) Transmission of the metadata needed to update the information recorded about a case that is maintained in a
courtrsquos CMS Messages returned to the sender that confirm a courtrsquos receipt of the senderrsquos filing message Messages notifying the sender of events such as the entry of the document(s) submitted by the sender into the
court record (or an error message stating that the document[s] could not be accepted for filing and stating the reason[s] why)
Queries to the court seeking information about data and documents held within the courtrsquos official electronic records and the return of information in response to those queries
Queries from filers for the court rules and requirements for electronic filing Queries by filers seeking from the court record system the names and addresses of parties in a case who must
be served and whether by traditional or electronic means Transmission of copies of documents submitted for filing to the other parties in a case who are registered to
receive service electronically
In addition to filing of court case documents this specification supports ldquosecondary servicerdquo ndash the delivery of copies of filed documents to persons who have already been made parties to a case This specification does NOT support ldquoprimary servicerdquo which entails the service of summonses subpoenas warrants and other documents that
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 8 of 61
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
establish court jurisdiction over persons making them parties to a case Therefore this specification does NOT support the following automated information exchanges A query by a filer seeking from the court record system the names and addresses of parties in a new case who
must be served to establish court jurisdiction over them in the new case Transmission of copies of or links to documents submitted for filing to any party in a new case or any newly
added parties in an existing case
This specification defines a set of core structures that are common to most types of court filings and defines specific structures that apply to filing documents in the following types of court cases Appellate Bankruptcy Civil (including general civil mental health probate and small claims) Criminal (both felony and misdemeanor) Domestic relations (including divorce separation child custody and child support domestic violence and
parentage ie maternity or paternity) Juvenile (both delinquency and dependency) Violations (including traffic ordinances and parking)
Although ECF 40150 does not define data structure elements specific to other case types (eg administrative tribunals) the basic structure will support other types of court filings and is extensible through court-specific and case-type-specific extensions
12 Relationship to Prior SpecificationsElectronic Court Filing 540 superseded the LegalXML Electronic Court Filing 30 301 and 31 40 and 401 specifications developed by the predecessor organizations to the OASIS Electronic Court Filing Technical Committee Those specifications were prepared for and approved by the COSCANACM Joint Technology Committee as proposed standardsRelative to the ECF 30 301 and 3140 and 401 specifications the ECF 40 and 40150 specifications provide a number of enhancements including Support for scheduling of court hearings Support for electronic delivery of filings to process servers (limited electronic service of process) Optional expressions of court policies using the LegalRuleML specifications Support for security roles and groups Enhanced support for paper on demand and court forms Support for a alternate ldquopullrdquo mode of publishing filings to court record systems Leveraging of Conformance with the 30 version of the National Information Exchange Model ([NIEM]) a
national standard for information sharing and new NIEM domains including Biometrics and Children Youth and Family Services
Clarifications and improvements throughout the specification based on feedback from implementers of of the ECF 40 and 401 specifications
Leveraging of the updates to the OASIS Universal Business Language ([UBL]) for describing paymentsThe inclusion of the data elements needed for appellate cases
This specification does not assume that prior specifications will be deprecated However ECF 450 is not backward-compatible and applications using the ECF 30 301 and 31 40 and 401 specifications will not
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 9 of 61
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
interoperate successfully with applications using these specifications This fact is indicated by the assignment of a new major version number to the ECF 40 and 40150 specifications
[13] ECF Version 40150 ECF Version 50 is a major release that adds new functionality and capabilities beyond the scope of the ECF 40 and 401 specifications that it supercedesECF 401 is a maintenance release to address several minor schema and definition issues identified by implementers of the ECF 40 specification All references in this document to ECF 40 apply to ECF 401 as well Relationship to other XML SpecificationsThe ECF specification incorporates other existing non-proprietary XML specifications wherever possible In particular the specification has dependencies on the [NIEM] the [UBL] data library and the World Wide Web Consortium (W3C) XML Digital Signatures specification The terminology used in this specification to describe the components of the ECF technical architecture conforms to the OASIS Reference Model for Service Oriented ArchitectureIt is recommended that implementations cache external schemas locally to improve performance and reliability (The alternative would be to rely on the external schemas as they are in someone elsersquos control and assume they will not be changed or become hard to access due to Internet or network problems) The copies of external schemas that are cached in this way should be updated and refreshed often to ensure changes will be quickly learned and addressed
121[131] National Information Exchange Model (NIEM)[NIEM] conformance as defined by the NIEM Implementation Guidelines ([NIEM Guide]) is a core objective of this specification The [NIEM] is an XML standard designed specifically for justice information exchanges providing law enforcement public safety agencies prosecutors public defenders and the judicial branch with a tool to effectively share data and information in a timely manner The [NIEM] provides a library of reusable components that can be combined to automate justice information exchanges The [NIEM] removes the burden from agencies to independently create exchange standards Because of its extensibility there is more flexibility to deal with unique agency requirements and changes Through the use of a common vocabulary that is understood system to system [NIEM] enables access from multiple sources and reuse in multiple applications The use of [NIEM] element names does not require any change in local legal terminology XML tag names are invisible to the user of an application employing themThe [NIEM] is most useful for describing common objects such as persons and locations and criminal justice-specific processes such as arrest booking jail and prosecution The [NIEM] is not as well developed for describing non-criminal information exchanges and processes ECF 40 uses the [NIEM] version 20 where the structures and definitions correspond to the requirements of ECF 40 The development process including the [NIEM] modeling process is described in Appendix B
122[132] OASIS Universal Business Language[UBL] is an OASIS Standard that provides a single ubiquitous language for business communication and takes into account the requirements common to all enterprises [UBL] provides a shared library of reusable components essential to interoperability that can be combined to create electronic business schemas Without a common set of base components each document format would risk redefining addresses locations and other basic information in incompatible ways1
ECF 40 employs the following structures in the [UBL] to describe filing payments and payment receiptsltAllowanceChargegt
Information about a charge or discount price componentltAddressgt
Information about a structured address
1 httpwwwoasis-openorgcommitteesdownloadphp1023UBL3A20The20Next20Step20for20Global20E-Commerce
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 10 of 61
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
ltPaymentgt
Information directly relating to a specific payment
123[133] W3C XML-Signature Syntax and ProcessingThe W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data [XMLSIG] defines standard means for specifying information content that is to be digitally signed2 ECF 40 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 40 message transmission in order to provide authentication encryption and message integrity [XMLSIG] is also used in the ECF 40 XML Document Signature Profile
124[134] OASIS Reference Model for Service Oriented ArchitectureThe [SOA-RM] is a framework for understanding significant entities and the relationships between those entities within a service-oriented architecture ECF 40 describes such an architecture and includes terminology that conforms to the [SOA-RM]
125[135] OASIS Code List Representation (Genericode)The OASIS Code List Representation format [Genericode] is a model and XML schema that can be used to encode a broad range of code list information The XML format is designed to support interchange or distribution of machine-readable code list information between systems All ECF 40 code lists that are not defined in the NIEM are provided in [Genericode] 10 format
126 OASIS LegalRuleMLTODO
13[14] Terms and DefinitionsThe keywords ldquoMUSTrdquo ldquoMUST NOTrdquo ldquoREQUIREDrdquo ldquoSHALLrdquo ldquoSHALL NOTrdquo ldquoSHOULDrdquo ldquoSHOULD NOTrdquo ldquoRECOMMENDEDrdquo ldquoMAYrdquo and ldquoOPTIONALrdquo in this document are to be interpreted as described in [RFC2119]
This section defines key terms used in this specification
AttachmentSee definition in Section 232
Callback messageA message transmission returned by some operations some time after the operation was invoked (asynchronously)
DocumentAn electronic equivalent of a document that would otherwise be filed on paper in a traditional non-electronic fashion
Document hashA condensed representation of a document intended to protect document integrity calculated according to the FIPS 180-2 SHA 256 algorithm
2 httpxmlcoverpagesorgxmlSightml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 11 of 61
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
DocketingThe process invoked when a court receives a pleading order or notice with no errors in transmission or in presentation of required content and records it as a part of the official record
FilerAn attorney or a pro se (self-represented) litigant acting as an individual who assembles and submits one or more filings (combinations of data and documents)
FilingAn electronic document (with any associated data attachments and the like) that has been assembled for the purpose of being filed into a specified court case
Hub Service MDEA centralized Service MDE capable of receiving a single set of service notifications for all parties registered for electronic service in a case and transmitting the service notifications to the Service MDEs registered to each party in the case
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by ECF 40 Each MDE operation receives one or more messages returning a synchronous response message (a reaction to a message received) and optionally returning an asynchronous (later) response message to the originating message sender
MessageSee definition in Section 231
Message TransmissionThe sending of one or more messages and associated attachments to an MDE Each transmission must invoke or respond to an operation on the receiving MDE as defined in the ECF 40 specification
Operation (or MDE Operation)A function provided by an MDE upon receipt of one or more messages The function provided by the operation represents a significant step in the court filing business process A sender invokes an operation on an MDE by transmitting a request with an operation identifier and a set of messages
Operation signatureA definition of the input message and synchronous response message associated with an operation Each message is given a name and a type by the operation The type is defined by a single one of the message structures defined in the ECF 40 specification
Synchronous responseA message transmission returned immediately (synchronously) as the result of an operation Every operation has a synchronous response
14[15] Symbols and AbbreviationsThis section defines key symbols and abbreviations used in this specification
BIECBusiness Information Exchange Components
ECF 540Electronic Court Filing 5040
IEPDInformation Exchange Package Documentation
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 12 of 61
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
MDEMajor Design Element
MPDModel Package Description
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WS-IWeb Services Interoperability Organization
15[16] Normative References[FIPS 180-2]Secure Hash Standard httpcsrcnistgovpublicationsfipsfips180-2fips180-2withchangenoticepdf National
Institute for Standards and Technology August 2002[Genericode]A B Coates Code List Representation (Genericode) 10
httpdocsoasis-openorgcodelistnsgenericode10 OASIS Committee Specification December 28 2007
[LegalRuleML]M Palmirani G Governatori LegalRulML Core Specification Version 10 Working Draft 01 httpswwwoasis-
openorgappsorgworkgrouplegalrulemldownloadphp49714legalruleml-core-spec-wd03doc OASIS Working Draft June 26 2013
[NIEM]National Information Exchange Model 320 httpniemgov US DOJ and DHS and HHS 201307
[NIEM Guide] NIEM Implementation Guidelines httpwwwniemgovimplementationguidephp US DOJ and DHS 2007
[NIEM MPD]NIEM Model Package Description 11 httpreferenceniemgovniemspecificationmodel-package-description11model-package-description-11pdf US DOJ DHS and HHS 2012
[NIEM Techniques] Techniques for Building and Extending NIEM httpwwwniemgovtopicIndexphptopic=techPDF Georgia Tech Research Institute August 2007
[Namespaces]T Bray Namespaces in XML httpwwww3orgTR1999REC-xml-names-19990114 January 14 1999
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 13 of 61
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
[RFC2046]N Freed Multipurpose Internet Mail Extensions (MIME) Part Two Media Types
httpwwwietforgrfcrfc2046txt IETF RFC 2046 November 1996[RFC2119]S Bradner Key words for use in RFCs to Indicate Requirement Levels httpwwwietforgrfcrfc2119txt IETF
RFC 2119 March 1997[RFC4122]Leach et al A Universally Unique IDentifier (UUID) URN Namespace httpwwwietforgrfcrfc4122txt IETF
RFC 4112 July 2005[Schema Part 1]H S Thompson D Beech M Maloney N Mendelsohn XML Schema Part 1 Structures Second Edition
httpwwww3orgTR2004REC-xmlschema-1-20041028 W3C Recommendation October 28 2004
[Schema Part 2]P Biron A Malhotra XML Schema Part 2 Datatypes Second Edition httpwwww3orgTR2004REC-
xmlschema-2-20041028 W3C Recommendation October 28 2004[UBL] Universal Business Language Version 21 30 May 2011 30 May 201129 June 2013 Committee Specification 01Draft 02 Public Review Draft 02httpdocsoasis-openorgublcs1-UBL-21UBL-21html
httpdocsoasis-openorgublprd2-UBL-21UBL-21htmlJ Bozak T McGrath G K Holman (editors) Universal Business Language 20 OASIS Standard December
12 2006[[XML 10]T Bray Extensible Markup Language (XML) 10 (Third Edition) httpwwww3orgTRREC-xmlREC-XML-
20040204 W3C Recommendation February 4 2004[XMLENC]
D Eastlake J Reagle XML Encryption Syntax and Processing httpwwww3orgTR2002REC-xmlenc-core-20021210 W3C Recommendation December 2002
[XMLSIG]D Eastlake J Reagle D Solo XML-Signature Syntax and Processing httpwwww3orgTR2002REC-xmldsig-core-20020212 W3C Recommendation February 2002
16[17] Non-Normative References[Court Document]OASIS LegalXML Court Document SubcommitteeCharter July 2006
httpwwwoasis-openorgcommitteesdownloadphp19120DocumentSC-Charter-Rev6-1txt
[NIEM MNDR]W Roberts S Liebeskind M Kindl National Information Exchange Model Naming and Design Rules Draft 12
httpwwwniemgovtopicIndexphptopic=file-NDR-lineNum August 7 2007[Juvenile XML]S Rondendell et al Juvenile Justice XML Report
httpwwwijisorgdbsharepublicLibraryPublicationsjuvenile5fjustice5fxml5ffinal5freport5f20050630pdf IJIS Institute July 2005
[NIEM]NIEM Concept of Operations httpwwwniemgov DOJDHS October 7 2005[NCSC Guide]
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 14 of 61
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
State Court Guide to Statistical Reporting httpwwwncsconlineorgD_Researchcsp2003_FilesCompleteGuide11_02_04pdf National Center for State Courts November 2004
[Rap Sheet]Interstate Criminal History Transmission Specification XML Version 300 httpwwwsearchorgfilespdfCH_transmission_specpdf Joint Task Force on Rap Sheet Standardization February 2005
[SOA-RM]MacKenzie et al Reference Model for Service Oriented Architecture 10
httpwwwoasis-openorgcommitteestc_homephpwg_abbrev=soa-rm OASIS Public Review Draft 10 February 10 2006
[Traffic IEPD] Traffic Citation IEPD httpwwwncsconlineorgd_techgjxdmiepdcitationTraffic_Citation_08_08_2005zip
National Center for State Courts August 8 2005
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 15 of 61
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
[2] ECF 540 Architecture
The ECF 540 architecture consists of four Major Design Elements (MDEs) which support operations and messages An MDE is a logical grouping of operations such as the operations involved in creating a filing or the operations involved in receiving and recording a filing that is incorporating the constituent documents into a court document management system A message is the data exchanged between MDEs in the form of an XML document that may include one or more additional binary attachments These messages contain the information to be filed with the court This section describes the ECF 540 architecture including the MDEs the operations and the messages
17[21] Core vs ProfilesThe ECF 4050 architecture can be divided into three principal elements Core Specification ndash This core specification defines the MDEs and the operations and messages that are
exchanged between MDEs Service Interaction Profiles ndash Service interaction profiles are specifications that describe communication
infrastructures that deliver messages between MDEs Document Signature Profiles ndash Document signature profiles are specifications that describe mechanisms for
signing electronic documentsIn order to be compliant an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile and one document signature profileThe MDEs and messages that make up the core specification are discussed in Sections 22 and 23 below respectively Service interaction profiles are discussed in Section 5 below Document signature profiles are discussed in Section 6 below
18[22] Major Design ElementsECF 540 defines fiveour MDEs They are Filing Assembly MDE ndash enables a filer to create a filing message for submission to a court and for service on
other parties in the case returning a response from the court to the filer Filing Review MDE ndash enables a court to receivevalidate 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 Filing Assembly MDE The Filing Review MDE also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing
Court Record MDE ndash enables a court to record electronic documents and docket entries in its case management and document management systems and returns the results to the Filing Review MDE The Court Record MDE also enables filers to obtain service information for all parties in a case to obtain information about cases maintained in the courtrsquos docket register of actions and calendars and to access documents maintained in the courtrsquos electronic records
Legal Service MDE ndash 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 Filing Assembly MDE
Court Scheduling MDE ndash enables filers to query request and schedule court events that are related to filings and court cases
The MDEs defined in the ECF 4050 specifications are meant only to define the ldquointerfacerdquo to each operation the specification is not intended to define how operations must be implemented This strategy allows MDE implementations to interoperate while leaving room for vendors and courts to have differing implementations (eg an implementation that supports a particular CMS)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 16 of 61
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
An ECF 4050-compliant implementation may implement one or more of the MDEs defined in the specification but a complete ECF 4050 system MUST include at least one each of the Filing Assembly Filing Review and Court Record MDEs For instance a court may decide to provide certain MDEs and allow private providers to furnish the remaining MDEs When multiple MDEs are implemented by a single court vendor or application the application MUST maintain the ECF 4050 specified operations between each MDE so that other applications will be able to interoperate with it Each of the operations supported by an MDE accepts one or more messages as input and returns an immediate synchronous response message to the calling MDE For some operations the MDE will also return an asynchronous (callback) message at a later time that reports the result of a business process implemented within the MDE In order to be compliant with ECF 4050 an MDE must support all messages required for that MDE However in an ECF 4050 system that does not support electronic service the operations associated with the Legal Service MDE are not requiredAn MDE defines an information model and behavior model of a service as described in the [SOA-RM] One must remember that ldquoservicerdquo in the service oriented architecture sense is not the same as the business function of ldquoservice of filingrdquo used throughout in this document
19[23] Information ModelThe ECF information model describes the messages that may be exchanged between MDEs All ECF 4050 operations use the same core message stream structure which is implemented in the service interaction profiles Each ECF core message stream is a stream of bytes that contains at least one message and may also contain attachments
191[231] MessagesA message is an XML document that is a well-formed XML data structure with a single root element that is transmitted between MDEs and is valid as defined by one of the defined message structure schemas in the ECF 4050 specification A message may be related to one or more attachments A message contains the following information
Message information about the filing and court case such as identifiers for the sender and receiver the sending and receiving MDEs and the submission date and time typically a composition ofndash A core message which includes basic information common to all courts and case types and Information
about each of the documents associated with the messagendash Case-type-specific extensions that includes information appropriate only for a particular type of filingndash Court-specific extensions that includes information appropriate only for cases in a particular court
Information about each of the documents associated with the message A document in this sense is the electronic representation of what would be recognized as a ldquodocumentrdquo if it were a single whole physical paper object This includes both a lead document one that will be placed on the courtrsquos register of actions (docketed indexed) and any supporting document(s) which are present to supplement the lead document in some way The message includes the documentrsquos metadata for example its title type identifier parent document identifier and document sequence number Each document structure may reference one or more attachments including attachment identifiers and sequence numbers When included in attachments a logical document MAY be split into several physical parts if necessary to satisfy a court requirement regarding maximum document size The actual binary encoded electronic document MAY be either included in one or more attachments to the message or embedded in the message using the following structure
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)ltecfDocumentRenditiongt
ltDocumentRenditionMetadatagtltDocumentAttachmentgt
ltBinaryBase64Objectgt2345klj345hhellipltBinaryBase64ObjectgtltDocumentAttachmentgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 17 of 61
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
ltDocumentRenditionMetadatagtltecfDocumentRendition
ltFilingLeadDocumentgt (or ltFilingConnectedDocumentgt)
Elements defined by this specification whether in core messages case type-specific extensions or court-specific extensions are intended to be useful to an automated case management system for the purposes of partially or fully automating case workflow after filing (eg filing review noticing docketing judicial assignment calendaring standardized forms receipt and generation fee processing) or ascertaining the adequacy or appropriateness of the filing (eg fee or fine calculation jurisdiction) Elements defined by this specification are not intended to fully populate the automated case management system with all data contained within filed documents That is these elements should be useful as ldquofiling metadatardquo about the case the filing transaction parties or documents These elements may also be ldquofiling datardquo or the contents of the filings For instance information found on a filing cover sheet can generally be considered filing metadata even if the information is also repeated in the document(s) being filed
The scope of the ECF core messages and extensions is limited by the following criteria Elements in the ECF core messages should be applicable to most courts and case types Elements in the ECF case-type-specific extensions should only be applicable to one of the seven case types
defined in National Center for State Courts (NCSC) statistical standards Elements in locally-defined court-specific extensions should only be applicable to a particular court or court
system but not to courts in generalAll ldquofiling datardquo elements should be described in the filed documents whose structure is outside the scope of the ECF specification
192[232] AttachmentAn attachment is a series of bytes in the message stream transmitted between MDEs that constitutes in whole or in part an electronic document whose conventional equivalent would be a document on paper The contents are preceded by one or more ldquoheadersrdquo that uniquely identify the attachment (using a content identifier) and specify the format or type of the attachment Note that the contents of an attachment can be binary octets (the ldquorawrdquo binary data of the document) binary data encoded in text (eg via base-64 or some other algorithm) XML text or plain text
Attachments appear in the message stream after the messages The order of attachments within the message stream is not important and cannot be treated as significant In particular this means that the series of bytes representing the content of a lead document need not appear before the attachments representing the content of documents supporting that lead document
193[233] Sample Message StreamsThe following conceptual diagrams illustrate the containment structures involved in the message stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 18 of 61
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Figure 1 illustrates a message stream involving two lead documents the first of which has two supporting documents The second lead document has no supporting documents Each document is associated with a single attachment
Figure 1 Simple Message Stream
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 19 of 61
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Figure 2 illustrates a message stream involving two lead documents the first of which has a single supporting document The second lead document has no supporting documents The supporting document associated with the first lead document is split into two pieces each treated as an attachment presumably due to limits set by the court on size Each lead document is associated with a single attachment and the one supporting document is associated with two attachments
Figure 2 Message Stream with a Document in Multiple Attachments
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 20 of 61
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
110[24] Court PolicyA courtrsquos customary practices may influence many aspects of its ECF 4050 implementation and those local practices and variations are expressed through the ldquocourt policyrdquo component of e-filing which includes Human-readable court policy ndash a textual document publishing the courtrsquos rules and requirements for
electronic filing Machine-readable court policy ndash an ECF 4050 message that describes the features of the ECF 4050
implementation supported by this specification the courtrsquos code lists and any other information a Filing Assembly MDE would need to know in order to successfully submit an electronic filing into that court
The court MUST have only one active authoritative version of its policies at a given time both the human-readable and the machine-readable statements of those policies MUST have the same release dates for the court The courtrsquos human-readable and machine-readable court policies MUST each have a version numbering method associated with it The courtrsquos versioning process SHOULD comply with the following rules 1) Versions are denoted using a standard triplet of integers MAJORMINORPATCH 2) Different MAJOR versions are to be considered incompatible large-scale upgrades of the Policy 3) Different MINOR versions are to be considered to retain source and binary compatibility with earlier minor versions and changes in the PATCH level are perfectly compatible forward and backward It is important to note that a policy that has not reached version 100 is not subject to the guidelines described in this document Before a 10 release is achieved (ie any version numbered 0xy) court policy can be changed freely without regard to the restrictions on compatibility between versionsCourt policy is not directly equivalent to ldquoservice policyrdquo in the [SOA-RM] However thinking about court policy from a policy assertion policy owner and policy enforcement framework as described in the [SOA-RM] is helpful Note that ldquocourt policyrdquo refers to a set of constituent rules and requirements while the [SOA-RM] looks at each individual item as a ldquoservice policyrdquo In all cases the policy owner is the court where the document is to be filed Also note that none of the elements of court policy rise to the level of a ldquoservice contractrdquo as defined by the [SOA-RM]
1101[241] Human-Readable Court PolicyTo be compliant with the ECF 4050 specification each court MUST publish a human-readable court policy that MUST include each of the following1 The unique court identifier2 The location of the machine-readable court policy3 A definition of what constitutes a ldquolead documentrdquo in the court4 A description of how filer identifiers are to be maintained during electronic communications regarding the case5 A description of how the court processes (dockets) filings[6] A description of any instances in which the court will mandate an element that the ECF 4050 schema makes
optional6[7] A description of any restrictions to data property values other than code list restrictions (This restriction may
be removed in later versions of the ECF specification)7[8] Any other rules required for electronic filing in the court
1102[242] Machine-Readable Court PolicyMachine-readable Court Policy includes structures for identifying run-time and development-time policy informationRun-time information includes information that will be updated from time to time such as code lists (eg acceptable document types codes for various criminal charges and civil causes of action) and the courtrsquos public key for digital signatures and encryption Also included are the general court schedule that includes operating days and judge schedulesDevelopment-time information includes court rules governing electronic filing that are needed at the time an application is developed but which are not likely to change These include1 The service interaction profile(s) that the court supports
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 21 of 61
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
[2] The MDEs query operations and case types supported by the courtrsquos ECF 4050 system2[3] Whether a court will accept the filing of a URL in lieu of the electronic document itself3[4] Whether the court accepts documents requiring payment of a filing fee4[5] Whether the court accepts electronic filing of sealed documents5[6] Whether the court accepts multiple (batch) filings[7] The court-specific extensions to the ECF 4050 specification including the required elements (see below)6[8] The maximum sizes allowed for a single attachment and a complete message streamThe machine readable court policy MUST be provided to the Filing Assembly MDE either by the Filing Review MDE through the GetCourtPolicy query or some other means
1103[243] Case-Type and Court ExtensionsSchemas for initiating specific case types (eg criminal civil) are included in the specification Case-type and court-specific extensions to the ECF core messages are implemented through the methods described in [NIEM Techniques] The primary extension technique is the use of element substitution as described in Section 533 of [NIEM Techniques] in which a more specific element defined in a case-type or court-specific extension is used in place of a generic element in a core message For instance a court may add elements required for a particular case type (eg civil) by defining an extension schema that includes types (eg courtCivilCaseType) and elements (eg courtCivilCase) that substitute for ECF types (eg civilCivilCaseType) and elements (eg civilCivilCase) Similarly an implementation may substitute a court-specific code list for a generic code list defined in this specification
1104[244] Court-Specific Code ListsCode lists are used to constrain the allowable values for certain information in an ECF 4050 message The court SHOULD publish [Genericode] 10 code lists for each of the following code lists and reference each of these code lists in its court policy
ECF Code Lists Civil Case Type
ltFiduciaryTypeCodegt ltJurisdictionalGroundsCodegt ltReliefTypeCodegt
Domestic Case Type ltNoContactCodegt ltRequestToVacateCodegt
Common Types ltAliasAlternateNameTypeCodegt ltCaseAssociationTypeCodegt ltCaseOfficialRoleTextgt ltCaseParticipantRoleCodegt ltCauseOfActionCodegt ltCourtEventTypeCodegt ltEntityAssociationTypeCodegt ltErrorCodegt
Juvenile Case Type
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 22 of 61
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
ltDelinquentActApplicabilityCodegt ltDelinquentActDegreeCodegt ltDelinquentActSeverityCodegt ltDelinquentActSpecialAllegationCodegt ltDependencyAllegationCodegt ltGuardianAssociationTypeCodegt ltPlacementTypeCodegt
NIEM Code Lists JXDM
ltChargeEnhancingFactorTextgt ltCourtLocationCodegt ltRegisterActionDescriptionTextgt ltStatuteCodeIdentificationgt ltStatuteCodeSectionIdentificationgt ltStatuteOffenseIdentificationgt ltStatusOffenseCodeIdentificationgt
NIEM Core ltBinaryDescriptionTextgt ltCaseCategoryTextgt ltDriverLicenseCommercialClassCodegt ltFamilyKinshipCodegt
A non-normative [Genericode] code list with default values is provided for each of the code lists above with asterisks ()
If a court does not define allowable values for any of the above code lists in court policy then any value MUST be considered acceptable for that code
1105[245] Court-Specific Constraint SchemasThe cardinality of elements in the NIEM subset imported by the ECF is applied through the use of constraint schemas that define the minimum and maximum occurrence of elements in the NIEM subset Courts MAY enforce court-specific rules and code lists by creating court-specific constraint schemas This process creates a duplicate set of the ECF schemas and allows the customization of the cardinality of elements as needed If court-specific constraint schemas are used instance documents MUST validate against both the ECF schemas and the court constraint schemas
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 23 of 61
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
[3] ECF 540 Process ModelThis section details the interactions of the ECF 540 MDEs and the role of each MDE in the electronic filing and electronic service processes This section also enumerates the operations provided by each MDE and points to the operations provided by other MDEs that each MDE consumes
111[31] The Filing-Preparation-to-Docketing Process ModelThis model describes the sequence of operations in a basic filing cycle from Filing Preparation to Docketing This model involves three parties a Filer (represented by the Filing Assembly MDE) a Court (represented by the Filing Review and Court Record MDEs) and a Service Recipient (represented by the Legal Service MDE) The operations defined by ECF 4050 to support the processes in this cycle are listed below The operations in bold are required and MUST occur in every successful filing as long as sending and receiving MDEs are implemented The other operations are optional and MAY occur within a given filing GetPolicy GetServiceInformation GetFeesCalculation ReviewFiling ServeFiling RecordFiling NotifyDocketingComplete NotifyFilingReviewComplete ServeProcessAt any point during or after the ReviewFiling operation if the filing is accessible a party MAY access information through the following operations GetFilingList GetFilingStatusAt any point after the NotifyFilingReviewComplete operation if the case is accessible a party MAY access information through the following operations GetCaseList GetCase GetDocumentAt any point after the NotifyFilingReviewComplete operation a party MAY request a specific court date through the following operations GetCourtSchedule ReserveCourtDate AllocateCourtDateThese operations are depicted in the sequence diagram below The solid lines indicate invoked operations and the dashed lines indicate the synchronous responses to those operations
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 24 of 61
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Figure 4 Filing Preparation to Docketing Process Model
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 25 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 26 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 27 of 61
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
112[32] Business RulesThis section describes the business rules of the generic filing-preparation-to-docketing process that govern the ECF 4050 operationsECF 4050 includes an ltecfErrorCodegt element for returning errors in response to a query request Successful queries MUST return an ltecfErrorCodegt of ldquo0rdquo Failed queries MUST NOT return an ltecfErrorCodegt of ldquo0rdquo and SHOULD return an appropriate ltecfErrorCodegt value as defined in court policy
1121[321] GetPolicyThe Filing Assembly MDE MAY obtain a courtrsquos machine-readable court policy at any time by invoking the GetPolicy operation on the Filing Review MDE with the identifier for the court The Filing Review MDE returns the machine-readable court policy in a synchronous response The content of the machine-readable court policy is described in Section 242 This step may be omitted if the Filing Assembly MDE already has the current court policy
1122[322] GetServiceInformationThe Filing Assembly MDE MAY obtain the Courtrsquos service information for all parties in an existing case at any time by invoking the GetServiceInformation operation with the appropriate case number on the Court Record MDE The service list returned by the GetServiceInformation operation assists the filer in maintaining the filerrsquos service list and is not a substitute for the filerrsquos service list To provide this information the Court Record MDE MUST have access to the courtrsquos 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 Record MDE responds synchronously to the Filing Assembly MDE 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 meansIf the court provides a Hub Service MDE the electronic service information returned from this query MUST include the courtrsquos Service MDE ID for all case participants who have oneA 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 intermediariesThe duty to complete secondary service is upon the filer and not the court except when the court is the filerThe GetServiceInformation operation 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
1123[323] GetFeesCalculationThe Filing Assembly MDE MAY query for the fees associated with a filing by invoking the MDErsquos GetFeesCalculation operation with a filing as a parameter on the Filing Review MDE The Filing Review MDE responds synchronously with the fee calculation and optionally a list of the included charges This step may be omitted if there are no fees associated with filings in the court or the calculated fees are already known
1124[324] ReviewFilingThe Filing Assembly MDE MUST submit the filing to the court by invoking the ReviewFiling operation on the Filing Review MDE The ReviewFiling operation includes messages for the core filing including the case type-specific and court-specific extensions and the filing payment The processing of a ReviewFiling operation is dependent on court policy and MAY hold the request for manual review or MAY be automated to accept the filingThe Filing Review MDE responds synchronously with a receipt message that includes the filing identifier issued by the court
1125[325] ServeFilingAt approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY serve the entire filing to other parties in the case by invoking the ServeFiling operation on the ServiceMDE associated with the service recipient This operation MUST NOT be used to serve parties in a new case or to persons or organizations that have not yet been made party to the case The Legal Service MDEServeFiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 28 of 61
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
operation responds synchronously with an acknowledgement that the message will be delivered to the service recipient or with an errorIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transactionIf a court chooses to support electronic service then each Filing Assembly MDE MUST support service operations for the clients for which it provides Filing Assembly functionality
1126 ServeProcessThis operation MUST be used to request service of process to parties in a new case or to persons or organizations that have not yet been made party to the case At approximately the same time the Filing Assembly MDE submits the filing to the court the Filing Assembly MDE MAY request service from an organization recognized by the court for servce The ServeProcess operation responds synchronously with an acknowledgement that the message will be delivered to the service entity or with an error The service entity may be an individual or an organization responsible for executing the service of processSubsequent filing of a return of service with the court and any subsequent notifications SHALL be treated as any other court filing and as such are processed according to the Filing-Preparation-to-Docketing Process Model described aboveIf the court hosts a hub Service MDE the Filing Assembly MDE MAY send a message to the hub Service MDErsquos ServeFiling operation The hub Service MDE MUST then broadcast the message to each of the individual Legal Service MDErsquos ServeFiling operations and respond synchronously with a single ServiceResponseMessage to the Filing Assembly MDE conveying the results of each individual service transaction
1127[326] RecordFilingIf the clerk reviews and accepts the filing the Filing Review MDE MUST invoke the RecordFiling operation on the Court Record MDE The RecordFiling operation includes information from the ReviewFiling operation with any modifications or comments by the clerk The Court Record MDE responds synchronously with an acknowledgement of the request
1128[327] NotifyDocketingCompleteThe Court Record MDE MUST invoke the NotifyDocketingComplete operation on the Filing Review MDE as a callback message to the RecordFiling operation to indicate whether the filing was accepted or rejected by the court record system If the Court Record MDE rejected the filing an explanation MUST be provided If the Court Record MDE accepts the filing the docketing information (eg date and time the document was entered into the court record judge assigned document identifiers and next court event scheduled) MUST be provided The Filing Review MDE responds synchronously with an acknowledgement of the callback message
1129[328] NotifyFilingReviewCompleteIf the clerk rejects the filings or the Filing Review MDE receives the Notify Docketing Complete message the Filing Review MDE MUST invoke the NotifyFilingReviewComplete operation on the Filing Assembly MDE as a callback message to the ReviewFiling operation to indicate whether the filing was accepted and docketed by the clerk and court record system 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 integrityIf 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 The Filing Assembly MDE responds synchronously with an acknowledgement of the callback message
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 29 of 61
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
11210[329] GetFilingListThe Filing Assembly MDE MAY invoke the GetFilingList query operation on the Filing Review MDE to return a list of filings matching several criteria including the filer identifier the case number and the filed date within a certain time range The Filing Review MDE responds synchronously with a list of matching filings and the status of each filing
11211[3210] GetFilingStatusThe Filing Assembly MDE MAY invoke the GetFilingStatus query operation with the filing Identifier on the Filing Review MDE to return the status of the selected filing The Filing Review MDE responds synchronously with the matching filing and the status of the filing
11212[3211] GetCaseListThe Filing Assembly MDE MAY invoke the GetCaseList query operation on the Court Record MDE to return a list of cases matching several criteria including case number case participant or the filed date over a specific time range The Court Record MDE responds synchronously with a list of matching cases
11213[3212] GetCaseThe Filing Assembly MDE MAY invoke the GetCase query operation with a case number on the Court Record MDE to return information about the case including the case participants court docket and calendar events The Filing Assembly MDE may also limit the amount of case detail returned from the Court Record MDE by using a set of filters The Court Record MDE responds synchronously with the selected case information
11214[3213] GetDocumentThe 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
11215 GetCourtScheduleThe Filing Assembly MDE may use the Court Scheduling MDE getCourtSchedule operation to pull up the court schedule by participant attorney or caseDiscussion point Should the court schedule query
11216 ReserveCourtDateThe Filing Assembly MDE SHALL use the reserveCourtDate operation to request one or more court dates for a specific case where the number of dates allotted is dictated by court policy specifying alternative selection criteria if the reservation request cannot be accommodated If the initial date(s) request are rejected this message can be used again to request other date(s)
11217 AllocateCourtDateThe Court Scheduling MDE SHALL use the allocateCourtDate to finalize a court reservation made using the reserveCourtDate Discussion point there are potentially different ways of looking at actual allocationof the court date
113[33] Message Business RulesEach operation includes one or more messages as parameters The following business rules apply to the content of ECF 4050 messages
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 30 of 61
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
1131[331] Identifiers Identifiers are used to uniquely label people organizations and things in the ECF 4050 process The following conventions will be used to produce identifiers
11311[3311] Attachment IdentifiersAttachment identifiers MUST be unique within a message transmission A convention for assigning identifiers to each message and attachment in a message transmission has to be defined in each service interaction profile
11312[3312] Case IdentifiersCase identifiers (case numbers) are assigned by the court record system and MUST be unique within a court
11313[3313] Court IdentifiersCourt identifiers are locally assigned by the court administrator for a region (typically a state provincial or federal court administrator) and MUST be universally unique to a court but not necessarily to a particular court house branch or subunit of a court Court identifiers MUST conform to following convention ltInternet domain of the court administratorgtltunique identifier within the court systemgt Examples of conformant court identifiers include courtswagovsuperiorking nmcourtscomalbdcivil uscourtsgov100 courtsgovbccaappealThese are strictly examples and do not necessarily indicate actual courts
11314[3314] Document IdentifiersDocument identifiers are assigned by the court record system and MUST be unique within a court
11315[3315] Filing IdentifiersFiling identifiers MUST be unique within a court and will be generated by the court in response to a ReviewFiling operation
11316[3316] MDE IdentifiersThe address of an MDE MUST be unique within a given communications infrastructure The convention for defining MDE identifiers will be defined in each service interaction profile
11317[3317] Filer and Party IdentifiersIdentifiers for filers and parties to a case both persons and organizations MUST be unique within a case and will be generated by the court in response to a ReviewFiling operation The following is a non-normative example of an identifier for filer number 100
ltncPersonOtherIdentificationgtltncIdentificationIDgt100ltncIdentificationIDgtltncIdentificationCategoryTextgtECFFilerIDltncIdentificationCategoryTextgt
ltncPersonOtherIdentificationgt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 31 of 61
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
In addition to ltncPersonOtherIdentificationgt other elements that may contain a filer identifier include ltncOrganizationOtherIdentificationgt ltecfFilingPartyIDgt and ltecfFilingAttorneyIDgt
Attorneys MAY reference the parties they represent with party identifiers Self-represented litigants MAY be represented using both attorney and party elements for the same individual with a reference from the attorney element to the party element The attorney elements for a self-represented litigant SHOULD NOT include a bar number
1132[332] Code ListsCode Lists are used to constrain the allowable values for certain information in a message The following normative code lists are normative for all ECF 4050 implementations Court-specific code lists are listed in Section 244
ECF Code Lists Bankruptcy Case Type
ltDebtorTypeCodegt ltEstimatedAssetsValueLevelCodegt ltEstimatedDebtsValueLevelCodegt ltNatureOfDebtCodegt ltNumberOfCreditorsValueLevelCodegt
Common Types ltFilingStatusCodegt
Court Policy Response Message ltMajorDesignElementNameCodegt ltOperationNameCodegt
Service Receipt Message ltServiceStatusCodegt
NIEM Code Lists ANSI NIST
ltFingerPositionCodegt
JXDM ltChargeNCICCodegt ltDrivingIncidentHazMatCodegt ltDrivingJurisdictionAuthorityNCICLSTACodegt ltIdentificationJurisdictionNCICLISCodegt ltWarrantExtraditionLimitationCodegt
NIEM Core ltDocumentLangageCodegt ltDriverLicenseCommercialClassCodegt ltDrivingRestrictionCodegt ltLanguageCodegt ltLengthUnitCodegt ltLocationCountryFIPS10-4Codegt ltLocationCountyCodegt ltLocationStateUSPostalServiceCodegt
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 32 of 61
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
ltPersonCitizenshipFIPS10-4Codegt ltPersonEthnicityCodegt ltPersonEyeColorCodegt ltPersonHairColorCodegt ltPersonRaceCodegt ltPersonSexCodegt ltPersonUnionCategoryCodegt ltPhysicalFeatureCategoryCodegt ltVehicleColorPrimaryCodegt ltVehicleMakeCodegt ltVehicleModelCodegt ltVehicleStyleCodegt ltWeightUnitCodegt
Code lists defined using [Genericode] 10 are indicated with asterisks () The remaining code lists are defined in XSD schema definitions
1133[333] Message-Specific Business RulesThe following business rules apply to specific messages
11331[3331] CoreFilingMessageA CoreFilingMessage MUST express the name or names of the party or parties on whose behalf a document is filed and the party whose document is the subject of a responsive document being submitted for filing If a case refers to a single element using the legal term ldquoIn Rerdquo the filer SHOULD use the NIEM ltjCaseRespondentPartygt not the ltjCaseInitiatingPartygt element
A CoreFilingMessage MAY NOT include documents for transactions such as the payment of a criminal fine If a CoreFilingMessage includes documents the message MUST include only one level of connected and supporting documents If a CoreFilingMessage includes multiple renditions of the same document the ltncBinaryDescriptionTextgt element SHOULD be used to determine how to process multiple renditions of the same document The ltecfDocumentMetadatagt and ltecfDocumentRenditionMetadatagt structures MAY be extended to support more sophisticated workflow processes
11332[3332] FilingPaymentMessageECF 4050 supports multiple particular payment processes Information about a payment is included in the FilingPaymentMessage including the method of payment of the applicable fees eg electronic funds transfer credit or debit card charge to an escrow account held in the court or promise to pay in the future The payment MAY include a maximum amount for the payment if some latitude is needed to accomplish the filing
11333[3333] RecordDocketingMessageThe court record system SHOULD retain all complete message transmissions including any message envelopes and headers defined by the service interaction profile for evidentiary purposes
11334 ServiceOfProcessRequestMessageA ServiceOfProcessRequestMessage is means by which a request for service of process is sent to a service entity which is an individual or organization having the authority to execute the service of process It MUST specify the
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 33 of 61
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
type of service being requested where the ServiceRecipientID value matches the participant identifier as specified in section 3317 ldquoFiler and Party Identifiersrdquo The type of service is the physicl manner in which the service of process may be executed For example The court may be requested to execute the service of process by means of certified mail Altheratively physical delivery may be requested from the Sheriffrsquos office or another legimate process serverIf the court hosts a hub Service MDE the message MAY contain any number of service type requests for distribution by the hub
114[34] Filing the Record on AppealThis section describes the process for filing and subsequently amending the Record on Appeal (ROA) using ECF 4050
All ROA transactions either the original filing or subsequent amendments MUST contain as the lead document an Index of Record document that itemizes the content of the record on appeal 3
The documents that comprise the ROA transaction will be identified as supporting documents
The supporting documents that comprise the ROA transaction MAY also have additional attached documents
All ROA documents being submitted including the Index of Record document and each document within the record MUST have at least one court-defined document type that indicates the type of transaction to be performed on the document and whether the document is being added to or stricken from the record
The Index of Record document and each document within the ROA transaction MAY also have an additional document type or types which characterize the document for the Court Record MDE
When a document within the ROA transaction is being stricken from the court record the document MUST be identified by the unique document identifier which was provided by the Court Record MDE when the document was initially filed (See section 3314)
A hierarchical structure of case lineage elements MUST be used to express the target casersquos predecessor cases at prior courts Each predecessor case MAY also have its own predecessor case as necessary to express the full lineage of an appellate case4
3 There are no set requirements for the structure or content of the Index of Record document4 Explanation (non-normative) There is not always a one to one correspondence between a lower court case (ie a trial court case) and the target appellate case A single trial court case could have multiple descendent cases and a single appellate case can have multiple predecessors In the situation where an appellate case has multiple predecessor cases each predecessor case will send a record on appeal to the target court for the appellate case Each individual record will have an independent index of record The warning above against sending multiple ROA transactions while a prior transaction is still pending must be regarded in light of the record to which the transaction is intended (or if you prefer the predecessor case from which it originates) For example letrsquos say an appellate case has two predecessor cases case A and case B If an ROA transaction for the record from case A is pending (awaiting acceptance or rejection) this will not have any potential adverse impact on an ROA transaction from case B Similarly if a single lower court case were on appeal in two different appellate cases (say case Y and case Z) then while an ROA transaction targeted to case Y is pending there is no potential adverse impact to case Z receiving an ROA transaction (assuming of course that case Z does not also have a pending ROA transaction from the same predecessor case)
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 34 of 61
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
When the ROA transaction is electronically transferred from one court to another the target case number in the destination court and the case lineage which includes the predecessor case number in the sending court MUST be provided
If the ROA transaction is a case initiating filing in the destination court then the FilingCase object MUST be present and the CaseTrackingID MUST be absent
Each predecessor case identified in the target casersquos case lineage may include case type-specific and
court-specific extensions The case type and the case type-specific extensions for each predecessor case MUST be consistent throughout the case lineage
When a ROA amendment transaction is sent the Index of Record document MUST reflect the status of the record assuming that the transaction will be accepted If however the transaction is rejected there will be ramifications for other pending amendment transactions for the same ROA in the same target case 5
While an ROA transaction is awaiting acceptance or rejection in the destination court and when the target case consists of multiple records courts SHOULD NOT send additional amendment transactions intended for the same record for the same target case
Individual documents within the ROA transaction MUST not be individually accepted or rejected All documents within the ROA transaction MUST have the same acceptance or rejection disposition
5 While an ROA transaction is awaiting acceptance or rejection in the destination court courts are cautioned against but not prohibited from sending additional amendment transactions for the same record in the same target case regardless of whether the case contains one or many records
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 35 of 61
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
[4] ECF 540 SchemasThe Court Filing XSD schemas are implementations of the ECF 4050 exchange content models (see Appendix B3 below) They are the only normative representations of ECF 4050 messagesAll of the ECF 4050 XSD schemas are contained in the xsd subdirectory of the ECF 4050 release package (see Appendix A for more information regarding the structure of the release package) The xsd directory is further subdivided into the xsdcasetype xsdcommon xsdconstraint xsdmessage and xsdSubset subdirectories
[41] ECF 4050 Case Type SchemasThe XSD schemas that define extensions specific to certain ECF 4050 case types are included in the xsdcasetype directory as listed below
AppellateCasexsdcasetypeECF-540-AppellateCasexsd
BankruptcyCasexsdcasetypeECF-540-BankruptcyCasexsd
CitationCasexsdcasetypeECF-540-CitationCasexsd
CivilCasexsdcasetypeECF-540-CivilCasexsd
CriminalCasexsdcasetypeECF-540-CriminalCasexsd
DomesticCasexsdcasetypeECF-540-DomesticCasexsd
JuvenileCasexsdcasetypeECF-540-JuvenileCasexsd
[42] ECF 4050 Common SchemasThe XSD schemas that define the generic elements and types that are common to multiple ECF 4050 messages andor case types are located in the xsdcommon folder as listed below
AppInfoxsdcommonECF-4050-AppInfoxsd
CommonTypesxsdcommonECF-4050-CommonTypesxsd
DigitalSignaturexsdcommonxmldsig-core-schemaxsd
Genericode
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 36 of 61
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
xsdcommongenericodexsd
[43] ECF 540 Constraint and Subset SchemasThe XSD schemas that define the subset of all NIEM elements and types that are used in ECF 4050 messages andor case type extensions are located in the xsdSubsetniem folder As a general data model NIEM does not define any constraints regarding the minimum and maximum occurrence of elements contained within types Therefore in conformance with NIEM ECF-specific constraints are not included in the schemas within the xsdSubsetniem folder The XSD schemas in the xsdconstraintniem folder represent the NIEM subset schemas with the ECF-specific constraints applied and are the schemas by which the ECF message and case type schemas incorporate NIEM elements and types
[44] ECF 4050 Message SchemasThe XSD schemas defining the messages that support the ECF 4050 processes are located in the xsdmessages folder as listed below
CaseListQueryMessagexsdmessageECF-4050-CaseListQueryMessagexsd
CaseListResponseMessagexsdmessageECF-4050-CaseListResponseMessagexsd
CaseQueryMessagexsdmessageECF-4050-CaseQueryMessagexsd
CaseResponseMessagexsdmessageECF-4050-CaseResponseMessagexsd
CoreFilingMessagexsdmessageECF-4050-CoreFilingMessagexsd
CourtPolicyQueryMessagexsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessagexsdmessageECF-4050-CourtPolicyResponseMessagexsd
DocumentQueryMessagexsdmessageECF-4050-DocumentQueryMessagexsd
DocumentResponseMessagexsdmessageECF-4050-DocumentResponseMessagexsd
FeesCalculationQueryMessagexsdmessageECF-4050-FeesCalculationQueryMessagexsd
FeesCalculationResponseMessagexsdmessageECF-4050-FeesCalculationResponseMessagexsd
FilingListQueryMessagexsdmessageECF-4050-FilingListQueryMessagexsd
FilingListResponseMessagexsdmessageECF-4050-FilingListResponseMessagexsd
FilingStatusQueryMessagexsdmessageECF-4050-FilingStatusQueryMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 37 of 61
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
FilingStatusResponseMessagexsdmessageECF-4050-FilingStatusResponseMessagexsd
MessageReceiptMessagexsdmessageECF-4050-MessageReceiptMessagexsd
PaymentMessagexsdmessageECF-4050-PaymentMessagexsd
PaymentReceiptMessagexsdmessageECF-4050-PaymentReceiptMessagexsd
ProcessServiceMessagexsdmessage ECF-40-ProcessServiceMessagexsd
RecordDocketingCallbackMessagexsdmessageECF-4050-RecordDocketingCallbackMessagexsd
RecordDocketingMessagexsdmessageECF-4050-RecordDocketingMessagexsd
ReviewFilingCallbackMessagexsdmessageECF-4050-ReviewFilingCallbackMessagexsd
ServiceInformationQueryMessagexsdmessageECF-4050-ServiceInformationQueryMessagexsd
ServiceInformationResponseMessagexsdmessageECF-4050-ServiceInformationResponseMessagexsd
ServiceReceiptMessagexsdmessageECF-4050-ServiceReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 38 of 61
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
2[5] Service Interaction ProfilesAn ECF 4050 service interaction profile defines a transmission system that supports the functional requirements of electronic filing along with the MDE operations and message structures and implements certain non-functional requirements A service interaction profile does not govern the content of messages ndash message content is described in Sections 2 and 3 of this specification A service interaction profile will define how a message gets from the sending MDE to the receiving MDE in a given messaging framework
21[51] Service Interaction Profile RequirementsEach service interaction profile will define standard conventions and configuration details to support interoperability between and among ECF 4050 implementations that support the same service interaction profile However compliance with these requirements will not necessarily guarantee interoperability To be compliant with the ECF 4050 specification a service interaction profile MUST satisfy the following non-functional requirements1 Transport protocol ndash A service interaction profile MUST define how messages are physically transported from
a sending MDE to a receiving MDE In so doing a profile may identify factors that restrict the range of environments in which the profile is applicable
2 MDE addressing ndash A service interaction profile MUST include a convention for uniquely addressing each MDE3 Operation addressing ndash A service interaction profile MUST describe a convention for uniquely addressing
each MDE operation4 Request and operation invocation ndash A service interaction profile MUST describe a mechanism for a sending
MDE to invoke an operation on the receiving MDE5 Synchronous mode response ndash A service interaction profile MUST support synchronous operations in which
the response to an operation is always returned immediately typically within a matter of seconds to the invoking MDE
6 Asynchronous mode response ndash A service interaction profile MUST support asynchronous operations in which the response to an operation may not necessarily be returned immediately to the invoking MDE Instead the response may be returned at some later time through a callback from the MDE that received the operations to the invoking MDE The callback MUST include a reference to the invoking message transmission
7 Messageattachment delimiters ndash A service interaction profile MUST define how the receiving MDE distinguishes messages from attachments within a message transmission
8 Message identifiers ndash A service interaction profile MUST provide a means for a sending MDE to assign a unique identifier to each message (including any attachments) within a message transmission
In addition there are some non-functional features that a service interaction profile SHOULD provide including1 Message non-repudiation ndash A service interaction profile SHOULD provide a mechanism so that the receiving
MDE is provided with evidence that demonstratesa the identity of the sending MDEb the content of the message(s) transmittedc the date and time of the message transmission
2 Message integrity ndash A service interaction profile SHOULD provide a mechanism so that the receiving MDE is able to determine whether the message(s) transmitted (including any attachments) was (were) modified during the message transmission
3 Message confidentiality ndash A service interaction profile SHOULD provide a mechanism such as encryption that can be used with a sending MDE to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 39 of 61
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
4 Message authentication ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to display credentials that demonstrate its identity to the receiving MDE in each message transmission
5 Message transmission reliability ndash A service interaction profile SHOULD provide a mechanism such that a sending MDE is required to include to guarantee that a message transmission will be delivered to the receiving MDE within a specified period of time or else the sending MDE will receive notification at the end of that period of time that the message transmission was not deliverable to the receiving MDE
6 Message splitting and assembly ndash A service interaction profile SHOULD provide a mechanism by which a large message and attachments MAY be split into multiple pieces that are transmitted separately by the sending MDE and reassembled into the complete message by the receiving MDE In the HTTP 11 protocol this is called ldquochunkingrdquo
7 Transmission auditing ndash A service interaction profile SHOULD provide a mechanism for the MDE to receive message transmissions in their entirety (both messaging and ldquopayloadrdquo content) for auditing purposes
22[52] Service Interaction Profile Approval and Revision ProcessesThe ECF Technical Committee (TC) will recommend certain service interaction profiles for use in implementations of the ECF 4050 specification The TC will consider a service interaction profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The service interaction profile MUST be described in a document in the format of an OASIS specification2 The service interaction profile specification MUST identify a unique URI to identify the service interaction profile
and version3 The service interaction profile specification MUST describe the binding of MDE operations to the service
interaction profile that satisfies the functional requirements described in Section 3 (ldquoECF 50 Process Modelrdquo) and Section 4 (ldquoECF 50 Schemardquo) of this specification
4 The service interaction profile specification MUST demonstrate that the service interaction profile satisfies the non-functional service interaction profile requirements described in Section 51 (ldquoService Interaction Profile Requirementsrdquo) of this specification
5 The service interaction profile specification MUST include samples that demonstrate how the messaging information and ldquopayloadrdquo content are combined into message transmissions These samples MUST include samples that demonstrate both synchronous and asynchronous mode operations
[6] At least one voting member of the ECF TC MUST agree to sponsor the service interaction profile and submit the service interaction profile specification to the TC for review as a candidate for approval as an ECF 4050 compliant service interaction profile
Certifying that a candidate service interaction profile meets certain service interaction profile requirements will necessarily involve some subjectivity since service interaction profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate in meeting the requirements of ECF 4050 before approving the service interaction profile specification as a ldquoCommittee Draftrdquo through the OASIS standards approval processFrom time to time it may be necessary to revise or update a service interaction profile to bring it into compliance with changes in network and messaging protocols or to support additional non-functional requirements Any revision(s) to previously approved service interaction profiles will be considered a new service interaction profile and MUST meet the requirements of a new service interaction profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of a service interaction profile will be backwardly compatible with the current version
23[53] Supported Service Interaction ProfilesThe following ECF 4050 service interaction profile specifications are for use in conjunction with implementations of the ECF 4050 specification
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 40 of 61
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Web Services Service Interaction Profile 20 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 WS-I Basic Security Profile 10 and OASIS WS-Reliable Messaging 11
Web Services Service Interaction Profile 21 Specification ndash This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 11 W3C SOAP 11 Binding for MTOM 10 and WS-I Basic Security Profile 11 and OASIS WS-Reliable Messaging 11
Portable Media Service Interaction Profile 101 Specification ndash This specification defines a transmission system in which the sending MDE stores message transmissions on portable media (eg a compact disc) which is then physically transported to the receiving MDE where it is connected for retrieval of the message transmissions This specification may be needed in the absence of an active network between the sending and receiving MDEs
Additional service interaction profiles or revisions to these service interaction profiles may be approved by the ECF TC for use in conjunction with implementations of the ECF 4050 specification according to the process described in Section 52 (ldquoService Interaction Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 41 of 61
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
3[6] Document Signature ProfilesAn ECF 4050 document signature profile defines a mechanism for asserting that a person signed a single electronic or imaged document which is an attachment to a message transmission The signing of an entire message transmission is described in a service interaction profile and is not supported by a document signature profile
31[61] Document Signature Profile RequirementsEach document signature profile will define standard conventions and configuration details to support interoperability in the creation and verification of document signatures between and among ECF 4050 implementations that support the same document signature profile However compliance with these requirements will not necessarily guarantee interoperability Except for the Null Document Signature Profile to be compliant with the ECF 4050 specification a document signature profile MUST satisfy the following non-functional requirements1 Signer name assertion ndash A document signature profile MUST make an assertion regarding the name of the
person who signed a document2 Signed date assertion ndash A document signature profile MUST make an assertion regarding the date the person
signed a document3 Multiple signatures ndash A document signature profile MUST allow multiple signatures to be associated with the
same documentA signature profile SHOULD provide the following non-functional features1 Signer and date non-repudiation ndash A document signature profile SHOULD provide a mechanism so that the
receiving MDE is provided with verifiable evidence that demonstratesa the unique identity of the person who signed the documentb the date the person signed a document
2 Document integrity ndash A document signature profile SHOULD provide a mechanism so that the receiving MDE is able to determine if the document was modified since the person signed the document
3 Document signature auditing ndash A document signature profile SHOULD provide a mechanism for the MDE to receive both the document and signatures for auditing purposes
32[62] Document Signature Profile Approval and Revision ProcessesThe ECF Technical Committee will recommend certain document signature profiles for use in implementations of the ECF 4050 specification The TC will consider a document signature profile for recommendation for use in ECF 4050 implementations provided the profile meets the following requirements1 The document signature profile MUST be described in a document in the format of an OASIS specification2 The document signature profile specification MUST identify a unique URI to identify the document signature
profile and version3 If the document signature is not embedded in the document the document signature profile specification MUST
include an XML structure for describing precisely how the document signature is represented4 The document signature profile specification MUST demonstrate that the document signature profile satisfies
the non-functional requirements described in Section 61 (ldquoDocument Signature Profile Requirementsrdquo) of this specification
5 The document signature profile specification MUST include samples that demonstrate how the document signature information and ldquopayloadrdquo content are combined into message transmissions
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 42 of 61
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
[6] At least one voting member of the ECF TC MUST agree to sponsor the document signature profile and submit the document signature profile specification to the TC for review as a candidate for approval as an ECF 4050 document signature profile
Certifying that a candidate document signature profile meets certain document signature profile requirements will necessarily involve some subjectivity since document signature profile requirements cannot be expressed algebraically in the manner of XML Schemas Therefore it will be up to the TC to assess whether the proposed profilersquos description is adequate to the requirements before approving the profile specification as a Committee Draft through the OASIS standards approval processFrom time to time it may be necessary to revise or update a document signature profile to bring it into compliance with changes in authentication and encryption protocols or to support additional non-functional requirements Any revision(s) to previously approved document signature profiles will be considered a new document signature profile and MUST meet the requirements of a new document signature profile including sponsorship by a voting member of the ECF TC and review and approval by the ECF TC There will be no guarantees that future versions of document signature profiles will be backwardly compatible with the current version
33[63] Supported Document Signature ProfilesThe following ECF 4050 document signature profile specifications are candidate Committee Drafts for use in conjunction with implementations of the ECF 4050 specification Null Document Signature Profile 10 Specification ndash This specification defines a default mechanism to
describe documents that do not have any associated signatures XML Document Signature Profile 10 Specification ndash This specification defines a mechanism for associating
a W3C XML Signature with a document Application-Specific Document Signature Profile 10 Specification ndash This specification defines a
mechanism for embedding an application-specific binary signature with a document This profile supports the native capabilities in document formats such as Microsoft Word and the Adobe Portable Document Format (PDF) for describing and embedding signatures
Proxy Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a court filing infrastructure component on behalf of an authenticated signer
Symmetric Key Document Signature Profile 10 Specification ndash This specification defines a mechanism for indicating documents that are digitally signed by a trusted entity on behalf of the signer using a symmetric key known only to the trusted entity
Additional document signature profiles or revisions to these document signatures profiles may be approved by the ECF TC for use in conjunction with implementation of the ECF 4050 specification according to the process described in Section 62 (ldquoDocument Signature Profile Approval and Revision Processesrdquo) above
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 43 of 61
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
4[7] ConformanceAn implementation conforms with the Electronic Court Filing Version 40150 if the implementation meets the requirements in Sections 1-6 including conformance with the XSD schemas and [Genericode] code lists referenced in Section 3 and 4
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 44 of 61
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Appendix A (Informative) Release NotesA1 AvailabilityOnline and downloadable versions of this release are available from the locations specified at the top of this document
A2 Package StructureThe ECF 4050 specification is published as a ZIP archive named ecf-v4050zip Unzipping this archive creates a directory named ecf-4050 containing this specification document and a number of subdirectories The files in these subdirectories linked to the specification document contain the various normative and informational pieces of the 10 release A description of each subdirectory is given below gc
[Genericode] 10 code lists model
ECF 4050 UML exchange content model diagrams and spreadsheet models see Appendix B3 and B4 xml
Example instances see Appendix D xsd
XSD schemas see Section 4
A3 Recursive StructuresCertain components in the [NIEM] version 20 schemas allow recursive nesting For example a ncCase may be related to another ncCase etc These are legitimate business data structures Most real-world applications will limit the depth of recursion in such structures but XSD schemas are incapable of expressing this constraint Implementers should be aware of this and may wish to set limits on the depth of recursive structures in their applications
A4 Date and Time FormatsThe date and time elements contained in the messages defined by the ECF 4050 XSD schemas should be formatted according to the documentation in the [NIEM] version 20 The [NIEM] documentation indicates the following Calendar date values should be expressed as ldquoCCYY-MM-DDrdquo with an optional time zone qualifier designated
by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Time values should be expressed as ldquohhmmsssssrdquo with an optional time zone qualifier designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)
Date and time values should be expressed as ldquoCCYY-MM-DDThhmmsssssrdquo with an optional time zone designated by appending -hh00 where hh represent the number of hours the local time zone is behind Coordinated Universal Time (UTC)qualifier
These formats are documented in but not enforced by the XSD schema at xsdconstraintniemproxyxsd20xsdxsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 45 of 61
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
A5 Known ErrataKnown errors in the ECF 4050 specification will be identified in an errata document available at httpwwwoasis-openorgcommitteeslegalxml-courtfiling
httpwwwoasis-openorgappsorgworkgrouplegalxml-courtfiling
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 46 of 61
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Appendix B (Informative) ECF 4050 Development Approach and ArtifactsThis appendix describes the approach used to develop ECF 4050 and the modeling artifacts
B1 PrinciplesThe key principles that guided the design of the ECF 4050 message structures were Interoperability ndash The ECF 4050 message structures should provide a means for exchanging court filings
among all types of court information systems Completeness ndash The ECF Filing 4050 message structures format should provide for all the elements of an
electronic filing system Simple implementation ndash The design should foster rapid implementation Simple XML and portable structure ndash The core messages in an ECF 4050 exchange will be formatted as
XML documents Familiarity ndash The data elements and code values should be meaningful to the legal community and non-expert
recipients alike Interdisciplinary and international utility ndash The design should be usable by a broad range of court-related
applications and should be applicable internationally
B2 ApproachThe ECF 4050 message schemas were developed as a [NIEM] Information Exchange Package Definition (IEPD) as defined by the Model Package Description [NIEM MPD] guidelines A NIEM IEPD[NIEM IEPD] is a collection of artifacts that describe the structure and content of a set of data that is transmitted for a specific business purpose Similarly the ECF 50 NIEM subset and extension schemas were developed as a NIEM Business Information Exchange Components (BIEC as defined by the [NIEM MPD] guidelines A NIEM BIEC is a set of data components that meet a specific business need and are a part of one or more information exchanges Neither the ECF IEPD nor the BIEC It does not specify other interface layers (such as Web services)
The NIEM Naming and Design Rules (MNDR) [NIEM NDR] describe best practices for the development of NIEM-conformant Information Exchange Packages and documentation The Design Rules set forth A methodology for the construction of [NIEM]-conformant exchange documents Naming and design rules for the artifacts called for by the methodology Guidelines for the customization of [NIEM] schema structures
B3 ECF 4050 Exchange Content ModelsThe ECF 4050 exchange content models describe the information components used in all of the messages defined by ECF 4050The exchange content models are the result of a detailed analysis of the data requirements to support the ECF 4050 Process Model (see Section 3) During the modeling process common items of data were identified by a process of normalization to identify aggregates based on functional dependency Where appropriate these were generalized so that they could be re-used to support the various messagesThe exchange content models are used for the following purposes They facilitate the identification of the reusable components ie the data structures that are common across
the ECF 4050 messages They aid in understanding the information requirements of the total scenario
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 47 of 61
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
They are the source from which the object classes are derived and documented in the ECF 4050 schemas (see Section 4)
To facilitate comprehension the ECF 4050 is composed of several exchange content model diagrams Each diagram represents a logical grouping of components and displays both the attributes and object classes belonging to the components in this grouping The scope of each diagram is arbitrary and does not hold any significance beyond these diagramsFor example the ECF 4050 Review Filing Model diagram is shown below
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 48 of 61
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 49 of 61
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
The complete set of exchange content models for all the ECF 4050 components is listed below
Appellate Filing ModelmodelumlhtmlAppellateFilingpng
Bankruptcy Filing ModelmodelumlhtmlBankruptcyFilingpng
Base Message ModelmodelumlhtmlBaseMessagepng
Civil Filing ModelmodelumlhtmlCivilFilingpng
Citation Filing ModelmodelumlhtmlViolation Filingpng
Criminal Filing ModelmodelumlhtmlCriminalFilingpng
Domestic Filing ModelmodelumlhtmlDomesticFilingpng
Extended Person Information ModelmodelumlhtmlExtendedPersonInformationpng
Get Calculated Fees Query ModelmodelumlhtmlGetFeesCalculationQuerypng
Get Case List Query ModelmodelumlhtmlGetCaseListQuerypngGet Document Query ModelmodelumlhtmlGetDocumentQuerypng
Get Filing List Query ModelmodelumlhtmlGetFilingListQuerypng
Get Filing Status Query ModelmodelumlhtmlGetFilingStatusQuerypng
Get Service Information Query ModelmodelumlhtmlGetServiceInformationQuerypng
Major Design Elements ModelmodelumlhtmlMajorDesignElementspng
Juvenile Filing ModelmodelumlhtmlJuvenileFilingpng
Record Docketing ModelmodelumlhtmlRecordDocketingpng
Review Filing ModelmodelumlhtmlReviewFilingpng
No specific directions are defined for the associations in these models they can be navigated in either direction The specific navigation path for each association is defined when documents are assembled
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 50 of 61
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
B4 Spreadsheet ModelsECF 4050 uses spreadsheet models to describe the mapping of objects and attributes to [NIEM] and ECF 4050 elements The spreadsheet models use rows to define components Components are either simple data types or associations Columns define the metadata associated with each component typeThe ECF 4050 spreadsheet model is located at modelECF-40-NIEM2-mappingxlsmodelECF-4050-NIEM2-mappingxls
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 51 of 61
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Appendix C[Appendix B] (Informative) MDE OperationsThis appendix details the operations that are provided by each Major Design Element (MDE) and the operations provided by other MDEs that each MDE ldquoconsumesrdquo Implementation of an MDE requires both that the MDE provide certain functionality and that the MDE use particular operations provided by other MDEs
C1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filed documents to a court for review and can receive the results of that process The Filing Assembly MDE also conveys filings to the Legal Service MDE for service on other case participants The Filing Assembly MDE calls operations in other MDEs and provides a single operation for notifying the submitter that the filing has been reviewed by a court A Filing Assembly MDE may be provided by a court or by a third party
C11 Provided OperationsThe Filing Assembly MDE provides the following operations to other MDEs
Operation Called By Output ParametersNotifyFilingReviewComplete
Filing Review MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-ReviewFilingCallbackMessagexsd ReviewFilingCallbackMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
C12 Consumed OperationsThe Filing Assembly MDE calls the following operations in other MDEs
Operation Provided By Return TypeGetPolicy Filing Review MDE xsdmessageECF-4050-CourtPolicyQueryMessagexsd
CourtPolicyReponseMessage
ReviewFiling Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
GetFeesCalculation Filing Review MDE xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
GetFilingStatus Filing Review MDE xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
GetFilingList Filing Review MDE xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
GetCase Court Record MDE xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
GetCaseList Court Record MDE xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
GetServiceInformation Court Record MDE xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
GetDocument Court Record MDE xsdmessageECF-4050-DocumentResponseMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 52 of 61
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
DocumentResponseMessage
ServeFiling Legal Service MDE xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
getCourtSchedule Court Scheduling MDE xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
reserveCourtDate Court Scheduling MDE xsdmessageECF-40-ScheduleReservationResponsexsd ScheduleReservationResponseMessage
C2 Filing Review MDEThe Filing Review MDE receives presents and manages the filings The Filing Review MDE receives filings in a standard format and presents those filings Depending on the court policy the filing may be presented to a Clerk for review where they may be accepted or rejected The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the filer that the filing has been accepted or rejected Alternatively the request may be automated to accept the filing if court policy allowsThe Filing Review MDE transmits data and documents for accepted filings to the Court Record MDE for docketing and recording While there will generally be one Filing Review MDE per court there is no physical barrier to having more than one particularly if a court wants to support different Filing Review MDEs for particular case types
C21 Provided OperationsThe Filing Review MDE provides the following operations to other MDEs
Operation Called By Output ParametersReviewFiling Filing
Assembly MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
xsdmessageECF-4050-PaymentMessagexsd PaymentMessage
NotifyDocketingComplete
Court Docketing MDE
xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingCallbackMessagexsd RecordDocketingCallbackMessage
GetFeesCalculation Filing Assembly MDE
xsdmessageECF-4050-FeesCalculationResponseMessagexsd FeesCalculationResponseMessage
xsdmessageECF-4050-FeesCalculationQueryMessagexsd FeesCalculationQueryMessage
GetFilingList Filing Assembly MDE
xsdmessageECF-4050-FilingListResponseMessagexsd FilingListResponseMessage
xsdmessageECF-4050-FilingListQueryMessagexsd FilingListQueryMessage
GetFilingStatus Filing Assembly MDE
xsdmessageECF-4050-FilingStatusResponseMessagexsd FilingStatusResponseMessage
xsdmessageECF-4050-FilingStatusQueryMessagexsd FilingStatusQueryMessage
GetPolicy Filing Assembly MDE
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyReponseMessage
xsdmessageECF-4050-CourtPolicyQueryMessagexsd CourtPolicyQueryMessage
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 53 of 61
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
C22 Consumed OperationsThe Filing Review MDE calls the following operations in other MDEs
Operation Provided By OutputRecordFiling Court Record MDE xsdmessageECF-4050-MessageReceiptMessagexsd
MessageReceiptMessage
NotifyFilingReviewComplete Filing Assembly MDE xsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C3 Court Record MDEThe Court Record MDE receives the filed documents from the Filing Review MDE and enters them into the official case record of the court The Court Record MDE notifies the Filing Review MDE that the filing has been filed
C31 Provided OperationsThe Court Record MDE provides the following operations to other MDEs
Operation Called By Output ParametersRecordFiling Filing Review
MDExsdmessageECF-4050-MessageReceiptMessagexsd MessageReceiptMessage
xsdmessageECF-4050-RecordDocketingMessagexsd RecordDocketingMessage
xsdmessageECF-405040-CoreFilingMessagexsd CoreFilingMessage
GetCase Filing Assembly MDE
xsdmessageECF-4050-CaseResponseMessagexsd CaseResponseMessage
xsdmessageECF-4050-CaseQueryMessagexsd CaseQueryMessage
GetCaseList Filing Assembly MDE
xsdmessageECF-4050-CaseListResponseMessagexsd CaseListResponseMessage
xsdmessageECF-4050-CaseListQueryMessagexsd CaseListQueryMessage
GetServiceInformation
Filing Assembly MDE
xsdmessageECF-4050-ServiceInformationResponseMessagexsd ServiceInformationResponseMessage
xsdmessageECF-4050-ServiceInformationQueryMessagexsd ServiceInformationQueryMessage
GetDocument Filing Assembly MDE
xsdmessageECF-4050-DocumentResponseMessagexsd DocumentResponseMessage
xsdmessageECF-4050-DocumentQueryMessagexsd DocumentQueryMessage
C32 Consumed OperationsThe Court Record MDE calls the following operations in other MDEs
Operation Provided By OutputNotifyDocketingComplete Filing Review MDE xsdmessageECF-4050-MessageReceiptMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 54 of 61
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
MessageReceiptMessage
AllocateCourtDate Court Scheduling MDE xsdmessageECF-x- AllocationResponseMessagexsd AllocationResponseMessage
C4 Legal Service MDEThe Legal Service MDE enables a filer or a court to electronically transmit copies of or links to electronically filed documents to other parties who are participating in the case and who are entitled to be promptly served with the electronically filed documents The Filing Assembly MDE transmits data and documents to the Legal Service MDE to inform the case participant that an electronic filing has been submitted to the court clerk The Legal Service MDE transmits a callback message to the Filing Assembly MDE requesting a notification to confirm receipt of the served document
C41 Provided OperationsThe Legal Service MDE provides the following operations to other MDEs
Operation Called By Output ParametersServeFiling Filing
Assembly MDE
xsdmessageECF-4050-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessageECF-4050-CoreFilingMessagexsd CoreFilingMessage
ServeProcess FilingAssemblyMDE
xsdmessageECF-40-ServiceReceiptMessagexsd ServiceReceiptMessage
xsdmessage ECF-40-ProcessServiceMessagexsd ServiceOfProcessRequestMessage
C42 Consumed OperationsThe Legal Service MDE does not call operations in other MDEs
C5 Court Scheduling MDETODO
C51 Provided OperationsThe Court Scheduling MDE provides the following operations to other MDEs
Operation Called By Output ParametersgetCourtSchedule Filing
Assembly MDE
xsdmessageECF-x-CourtScheduletQueryResponseMessagexsd CourtScheduletQueryResponseMessage
xsdmessage ECF-x-CourtScheduletQueryMessagexsd CourtScheduletQueryMessage
reserveCourtDate Filing Assembly MDE
xsdmessageECF-40-CourtDateScheduleReservationResponsexsd CourtDateScheduleReservationResponseMessage
xsdmessage ECF-40-ScheduleReservationxsd ScheduleCourtDateReservationRequestMessage
allocateCourtDate Court Docketing RecordMDE
xsdmessageECF-x- CourtDateAllocationResponseMes
xsdmessageECF-x- AllocationRequestMessagexsd
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 55 of 61
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
sagexsd CourtDateAllocationResponseMessage
CourtDateAllocationRequestMessage
C52 Consumed OperationsThe Court Scheduling MDE does not call operations in other MDEs
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 56 of 61
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Appendix D[Appendix C] (Informative) Example InstancesExample instances of each ECF 4050 message are provided in the xml subdirectory as listed below
FeesCalculationQueryMessagexmlECF-4050-FeesCalculationQueryMessagexml
FeesCalculationResponseMessagexmlECF-4050-FeesCalculationResponseMessagexml
CaseListQueryMessagexmlECF-4050-CaseListQueryMessagexml
CaseListResponseMessagexmlECF-4050-CaseListResponseMessagexml
CaseQueryMessagexmlECF-4050-CaseQueryMessagexml
CaseResponseMessagexmlECF-4050-CaseResponseMessagexml
CoreFilingMessage (Appellate case type)xmlECF-4050-CoreFilingMessage-Appellatexml
CoreFilingMessage (Criminal case type)xmlECF-4050-CoreFilingMessage-CriminalxmlCourtPolicyQueryMessage
xmlECF-4050-CourtPolicyQueryMessagexmlCourtPolicyReponseMessage
xmlECF-4050-CourtPolicyResponseMessagexmlDocumentQueryMessage
xmlECF-4050-DocumentQueryMessagexmlDocumentResponseMessage
xmlECF-4050-DocumentResponseMessagexmlFilingListQueryMessage
xmlECF-4050-FilingListQueryMessagexmlFilingListResponseMessage
xmlECF-4050-FilingListResponseMessagexmlFilingPaymentMessage
xmlECF-4050-PaymentMessagexmlFilingStatusQueryMessage
xmlECF-4050-FilingStatusQueryMessagexmlFilingStatusResponseMessage
xmlECF-4050-FilingStatusResponseMessagexmlMessageReceiptMessage
xmlECF-4050-MessageReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 57 of 61
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
PaymentReceiptMessagexmlECF-4050-PaymentReceiptMessagexml
RecordDocketingCallbackMessagexmlECF-4050-RecordDocketingCallbackMessagexml
RecordDocketingMessagexmlECF-4050-RecordDocketingMessagexml
ReviewFilingCallbackMessagexmlECF-4050-ReviewFilingCallbackMessagexml
ServiceInformationQueryMessagexmlECF-540-ServiceInformationQueryMessagexml
ServiceInformationResponseMessagexmlECF-4050-ServiceInformationResponseMessagexml
ServiceOfProcessRequestMessagexmlECF-40-ServiceInformationResponseMessagexml
ServiceReceiptMessagexmlECF-4050-ServiceReceiptMessagexml
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 58 of 61
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Appendix E[Appendix D] (Informative) Ongoing Work Items
The Electronic Court Filing TC plans to continue to revise and expand this specification through future versions Future versions of ECF will Address filings in administrative tribunals Address primary service (the delivery of documents such as summonses subpoenas and warrants that
establish a courtrsquos jurisdiction over a party) Consider how the specifications for filing of documents intended for filing with a court relate to specifications for
filing other documents eg property records in the offices of elected clerks of courts Incorporate feedback from ECF implementations Support future releases of the [NIEM] Support future [Court Document] specifications and integration optimizations Support non-case related filings into a court clerkrsquos office TODO
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 59 of 61
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
Appendix F (Informative) AcknowledgmentsThe following court organizations provided lists of data elements required for initiating cases in their case management information systems
Administrative Office of United States Courtso Bankruptcy Civil Criminal
Arizona Administrative Office of the Courtso Appellate
Fourth Judicial District Court Hennepin County Minneapoliso Criminal
King County Superior Court Washingtono Civil Criminal
Missouri Office of State Courts Administratoro Citation
Thirteenth Judicial District Orange County Florida (through vendor)o Civil Criminal Domestic relations Mental health Juvenile delinquencydependency Probate
Citation Utah State Courts
o Civil Criminal
The following individuals were members or voting members of the committee during the development of this specification
TODORolly Chambers American Bar Association John Messing American Bar Association Adam Angione Courthouse News Service Eric Eastman Doxpop LLC Robert DeFilippis Associate Chester Ensign Associate Gary Poindexter Associate Michael Alexandrou Judicial Council of Georgia Shawn Artrip Judicial Council of Georgia Robbie Diaz Judicial Council of Georgiar Hui Ji Judicial Council of Georgia Morgan Medders Judicial Council of Georgia Scott Edson LA County Information Systems Advisory Body Ali Farahani LA County Information Systems Advisory Body John Ruegg LA County Information Systems Advisory Body CJ Allen Maricopa County Robin Gibson Missouri Office of State Courts Admin James Cabral MTG Management Consultants LLC Thomas Clarke National Center for State Courts Diana Graski National Center for State Courts Jim Harris National Center for State Courts Jason Hill New York State Office of Court Administration DoT Robert OBrien Ottawa Courts Administration Service George Knecht PC Intellect LLC Mark Ladd Property Records Industry Assn Ron Bowmaster Utah Administrative Office of the Courts
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 60 of 61
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
[Appendix E] (Informative) Revision HistoryRev Date By Whom What
Wd01 2008-03-17 James Cabral Initial version
Wd02 2008-08-15 James Cabral Revision including complete IEPD
Wd03 2008-08-25 James Cabral Revisions based on August face to face meeting and initial testing
Wd04 2008-09-03 James Cabral Revised guidance on filing record on appeal (Section 34)
Wd01 2008-09-20 James Cabral Committee draft
401 2010-03-15 James Cabral Minor schema and definition changes based on feedback from implementers of the ECF 40 specification
Csd-01 2011-08-08 James Cabral Revised reference format Minor schema changes including correction of several constraints Addition of Section 135 and revision of Section 243 based on feedback from implementers
Csd-02 2011-10-18 James Cabral Updated UBL reference version 21
Csd-03 2012-02-07 James Cabral Minor changes to Appendx C (non-normative) Minor additions to the schema Revision of sections 241 242 31 and 3332 based on feedback from implementers
Wd01 2013-09-20 James Cabral Initial version
ecf-spec-v401-spec-os 23 May 2013csprd0321 February 2012
Standards Track Work Product Copyright copy OASIS Open 20132011 All Rights Reserved Page 61 of 61
- 1 Introduction
-
- 11 Scope
- 12 Relationship to Prior Specifications
- 13 ECF Version 40150
-
- 131 National Information Exchange Model (NIEM)
- 132 OASIS Universal Business Language
- 133 W3C XML-Signature Syntax and Processing
- 134 OASIS Reference Model for Service Oriented Architecture
- 135 OASIS Code List Representation (Genericode)
- 136 OASIS LegalRuleML
-
- 14 Terms and Definitions
- 15 Symbols and Abbreviations
- 16 Normative References
- 17 Non-Normative References
-
- 2 ECF 540 Architecture
-
- 21 Core vs Profiles
- 22 Major Design Elements
- 23 Information Model
-
- 231 Messages
- 232 Attachment
- 233 Sample Message Streams
-
- 24 Court Policy
-
- 241 Human-Readable Court Policy
- 242 Machine-Readable Court Policy
- 243 Case-Type and Court Extensions
- 244 Court-Specific Code Lists
- 245 Court-Specific Constraint Schemas
-
- 3 ECF 540 Process Model
-
- 31 The Filing-Preparation-to-Docketing Process Model
- 32 Business Rules
-
- 321 GetPolicy
- 322 GetServiceInformation
- 323 GetFeesCalculation
- 324 ReviewFiling
- 325 ServeFiling
- 326 ServeProcess
- 327 RecordFiling
- 328 NotifyDocketingComplete
- 329 NotifyFilingReviewComplete
- 3210 GetFilingList
- 3211 GetFilingStatus
- 3212 GetCaseList
- 3213 GetCase
- 3214 GetDocument
- 3215 GetCourtSchedule
- 3216 ReserveCourtDate
- 3217 AllocateCourtDate
-
- 33 Message Business Rules
-
- 331 Identifiers
-
- 3311 Attachment Identifiers
- 3312 Case Identifiers
- 3313 Court Identifiers
- 3314 Document Identifiers
- 3315 Filing Identifiers
- 3316 MDE Identifiers
- 3317 Filer and Party Identifiers
-
- 332 Code Lists
- 333 Message-Specific Business Rules
-
- 3331 CoreFilingMessage
- 3332 FilingPaymentMessage
- 3333 RecordDocketingMessage
- 3334 ServiceOfProcessRequestMessage
-
- 34 Filing the Record on Appeal
-
- 4 ECF 540 Schemas
-
- 41 ECF 4050 Case Type Schemas
- 42 ECF 4050 Common Schemas
- 43 ECF 540 Constraint and Subset Schemas
- 44 ECF 4050 Message Schemas
-
- 5 Service Interaction Profiles
-
- 51 Service Interaction Profile Requirements
- 52 Service Interaction Profile Approval and Revision Processes
- 53 Supported Service Interaction Profiles
-
- 6 Document Signature Profiles
-
- 61 Document Signature Profile Requirements
- 62 Document Signature Profile Approval and Revision Processes
- 63 Supported Document Signature Profiles
-
- 7 Conformance
- Appendix A (Informative) Release Notes
-
- A1 Availability
- A2 Package Structure
- A3 Recursive Structures
- A4 Date and Time Formats
- A5 Known Errata
-
- Appendix B (Informative) ECF 4050 Development Approach and Artifacts
-
- B1 Principles
- B2 Approach
- B3 ECF 4050 Exchange Content Models
- B4 Spreadsheet Models
-
- Appendix C (Informative) MDE Operations
-
- C1 Filing Assembly MDE
-
- C11 Provided Operations
- C12 Consumed Operations
-
- C2 Filing Review MDE
-
- C21 Provided Operations
- C22 Consumed Operations
-
- C3 Court Record MDE
-
- C31 Provided Operations
- C32 Consumed Operations
-
- C4 Legal Service MDE
- C41 Provided Operations
- C42 Consumed Operations
- C5 Court Scheduling MDE
- C51 Provided Operations
- C52 Consumed Operations
-
- Appendix D (Informative) Example Instances
- Appendix E (Informative) Ongoing Work Items
- Appendix F (Informative) Acknowledgments
- Appendix G (Informative) Revision History
-
top related