€¦ · Web viewwd-LegalXML-Specifications-01.doc. ... oasis-open.org?subject=Subscribe with the...

LegalXML Court Filing SpecificationWorking Draft 04, September 9, 2005Document identifier:

document.doc

Location:http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/

Editor:[List your editors here; check whether “Editor” header should be plural]

Contributors:Shane Durham, LexisNexisEric Tingom, eCorridor, Inc.Tom Clarke, Washington State Administrator for the CourtsScott Came, Justice Integration Solutions, Inc.Dallas Powell, Tybera Development Group, IncJames Cabral, MTG Management Consultants, LLC.Rex McElrath, Judicial Council of GeorgiaDonald Bergeron, LexisNexisJames Cusick, Wolters KluwerJohn M. Greacen, Greacen Associates, LLCRoger Winters, King County, Department of Judicial Administration

Abstract:This document defines the LegalXML COURT FILING Specification, consisting of a set of non-proprietary Web services and ebXML specifications, along with clarifications and amendments to those specifications, which promote interoperability.

Status:This document is a Working Group Draft and has NOT been accepted by the Working Group as reflecting but is to serve as the basis for discussions. It is a work in progress, and should not be considered authoritative or final; other documents will superseded this document.

Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the mailto:[email protected] list. To subscribe, send an email message to mailto:[email protected]?subject=Subscribe with the word "subscribe" as the body of the message.

document.doc 9-Sep-2005

Copyright © OASIS Open 2005. All Rights Reserved of 137

1

2

3

45

67

89

10111213141516171819202122

232425

26272829

303132

1

2

mailto:[email protected]?subject=Subscribe

mailto:[email protected]

mailto:[email protected]

http://www.oasis-open.org/spectools/docs/

Table of Contents1 Introduction................................................................................................................................................................................................4

1.1 Notational Conventions.........................................................................................................................................................................41.1.1 Visual Indicators.........................................................................................................................................................................5

2 Design Principles and Concepts................................................................................................................................................................62.1 Design Philosophy................................................................................................................................................................................62.2 Key Design Terms and Concepts.........................................................................................................................................................6

2.2.1 Requirements for Major Design Elements:.................................................................................................................................62.2.2 Requirements for Designing All Messages:...............................................................................................................................72.2.3 Court Policy.............................................................................................................................................................................122.2.4 Hash and Signatures...............................................................................................................................................................132.2.5 Archival Storage.......................................................................................................................................................................132.2.6 Date and Time Format.............................................................................................................................................................14

3 Major Design Elements............................................................................................................................................................................153.1 Filing Assembly MDE..........................................................................................................................................................................15

3.1.1 Filing Assembly Glossary.........................................................................................................................................................153.1.2 Filing Assembly Overview........................................................................................................................................................153.1.3 Filer Review Filing Callback Service........................................................................................................................................16

3.2 Filing Review MDE.............................................................................................................................................................................173.2.1 Filing Review Glossary.............................................................................................................................................................173.2.2 Filing Review Overview............................................................................................................................................................173.2.3 Review Filing Service...............................................................................................................................................................173.2.4 Record Docketing Callback Service.........................................................................................................................................18

3.3 Court Record MDE.............................................................................................................................................................................193.3.1 Court Record Glossary............................................................................................................................................................193.3.2 Court Record Overview............................................................................................................................................................193.3.3 Record Docketing into the Court Record Service.....................................................................................................................19

3.4 Service MDE.......................................................................................................................................................................................203.4.1 Service Glossary......................................................................................................................................................................203.4.2 Service Overview.....................................................................................................................................................................203.4.3 Serve Filing Service.................................................................................................................................................................20

3.5 Service Registry MDE.........................................................................................................................................................................213.5.1 Service Registry Glossary........................................................................................................................................................213.5.2 Service Registry Overview.......................................................................................................................................................213.5.3 Get Service Registry Information.............................................................................................................................................21

3.6 Query MDE.........................................................................................................................................................................................223.6.1 Query Glossary........................................................................................................................................................................223.6.2 Query Overview.......................................................................................................................................................................233.6.3 Calculate Fees.........................................................................................................................................................................233.6.4 Case List Service.....................................................................................................................................................................233.6.5 Case Service............................................................................................................................................................................243.6.6 Document Service....................................................................................................................................................................253.6.7 Filing List Service.....................................................................................................................................................................253.6.8 Filing Service...........................................................................................................................................................................263.6.9 Filing Status Service................................................................................................................................................................27

3.7 Court Policy MDE...............................................................................................................................................................................283.7.1 Court Policy Glossary..............................................................................................................................................................283.7.2 Court Policy Overview..............................................................................................................................................................283.7.3 Court Policy Service.................................................................................................................................................................28



33

34

353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182

3

4

4 Message Types........................................................................................................................................................................................294.1 ReviewFilingMessageType.................................................................................................................................................................294.2 ReviewFilingCallbackMessageType...................................................................................................................................................444.3 RecordDocketingMessageType..........................................................................................................................................................494.4 RecordDocketingCallbackMessageType............................................................................................................................................524.5 CourtPolicyMessageType...................................................................................................................................................................564.6 ServiceInformationQueryMessageType..............................................................................................................................................614.7 CalculatedFeesQueryMessageType...................................................................................................................................................644.8 CaseQueryMessageType...................................................................................................................................................................664.9 CaseListQueryMessageType.............................................................................................................................................................694.10 DocumentQueryMessageType......................................................................................................................................................724.11 FilingQueryMessageType.............................................................................................................................................................744.12 FilingListQueryMessageType........................................................................................................................................................774.13 FilingStatusQueryMessageType...................................................................................................................................................804.14 FilingPayment...............................................................................................................................................................................824.15 CaseTypeSpecificInformationType................................................................................................................................................89

4.15.1 Bankruptcy...............................................................................................................................................................................894.15.2 Civil..........................................................................................................................................................................................934.15.3 Criminal....................................................................................................................................................................................984.15.4 Domestic relations.................................................................................................................................................................1124.15.5 Juvenile..................................................................................................................................................................................1164.15.6 Traffic.....................................................................................................................................................................................123

4.16 Implementation Notes.................................................................................................................................................................1314.16.1 WebService Profile................................................................................................................................................................131

5 References.............................................................................................................................................................................................1325.1 Normative.........................................................................................................................................................................................132

Appendix A. Acknowledgments........................................................................................................................................................................133Appendix B. Revision History............................................................................................................................................................................135Appendix C. Notices.........................................................................................................................................................................................136



8384858687888990919293949596979899100101102103104105106107108109110111

112

5

6

1 IntroductionThis document is a Proposed Standard developed by the OASIS LegalXML Member Section Electronic Court Filing Technical Committee.

This document is intended to describe the information required for Electronic Court Filing 3.0 and the structure of that information. No information regarding the content of any pleading or other legal devices (e.g., contracts, orders, and judgments) is included, other than what is required to accomplish the intended task.

This specification is the product of a consensus process. Many items covered by the standard attracted valuable inputs from multiple viewpoints. The views about items were often not identical. When resolution of items needed to be reached, discussion on proposed resolutions were closed only when the question “Is there anyone cannot live with this?” was answered in the negative.

The Electronic Court Filing (ECF 3.0) provides an open, non-proprietary digital message format for all types of court filings, queries and related responses. ECF 3.0 addresses telecommunications method as part of messaging profiles. The ECF 3.0 Message format is compatible with emerging technologies such as Web services.

Key benefits of ECF 3.0 will include interoperability between courts, vendors, and the legal community and operational complexity by eliminating the need for multiple custom software interfaces to the many systems involved in filing court documents.

Electronic Court Filing 3.0 will support the submission of documents in the following case types:

bankruptcy

civil (including general civil, mental health, probate and small claims)

criminal (including felony and misdemeanor)

domestic relations (including divorce, separation, child custody and child support, domestic violence, maternity and paternity)

juvenile (including delinquency and dependency)

traffic

Although ECF 3.0 does not contain a separate set of data elements for that purpose, the basic structure will also support filings in appellate courts. Future versions of ECF 3.0 will enhance the metadata for appellate filings, address filings in administrative tribunals, address primary service (the delivery of documents such as summonses, subpoenas, and warrants that establish a court’s jurisdiction over a party), and consider how the standards for filing of documents intended for filing with a court relate to standards for filing other documents in the offices of elected clerks of courts.1

1.1 Notational Conventions The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

1 The OASIS Electronic Court Filing Technical Committee has established contact with the Property Records Information Association and will commence formal discussions with PRIA and with the Mortgage Banker’s Association's Mortgage Industry Standards Maintenance Organization (MISMO) to determine how court filing processes should interact with the non-court related filings received by elected clerks of court.



113114

115116117

118119120

121122123

124125

126

127

128

129

130

131

132

133134135136137

138

139140141

78910

11

12

1.1.1 Visual IndicatorsIn the following sections, different fonts are used to identify the meaning of the term. Except within the Document. Type Definition (XML Schema), the font size is 8 point.

The Arial font identifies the names of elements and attributes.

A Bold font, whether in Arial or Times New Roman, is used for emphasis or to identify the beginning of a

definition.

Courier New identifies XML Schema text. It is also used, when enclosed in quotation marks, to indicate user-supplied attribute values or other strings, including attribute values. The font size for the entirety of the XML Schema is reduced to 8 point.



142

143144145

146147

148149

150

151152153

154

13

14

2 Design Principles and Concepts 2.1 Design PhilosophyAmong the principles which guided the design of the Electronic Court Filing 3.0 Message were:

Interoperability First and foremost, the Electronic Court Filing 3.0 Message should provide a means for interoperable exchange of court filings among all types of court information systems.

Completeness The Electronic Court Filing 3.0 Message format should provide for all the elements of an effective public warning message.

Simple implementation The design should not place undue burdens of complexity on technical implementers.

Simple XML and portable structure The primary anticipated use of the Electronic Court Filing 3.0 Message is as an XML document.

Multi-use format One message schema supports multiple message types in various applications.

Familiarity The data elements and code values should be meaningful to the legal community and non-expert recipients alike.

Interdisciplinary and international utility The design should allow a broad range of applications in Court management and associated applications and should be applicable worldwide.

2.2 Key Design Terms and Concepts

2.2.1 Requirements for Major Design Elements:Note: The following requirements were used as a basis for design and review of the Electronic Court Filing 3.0 specification. This list is non-normative and not intended to be exhaustive.

Each implemented MDE MUST maintain both an input and output functions of each separate MDE in order to be in compliance.

Names in UML Domain Models will be normative, will govern and will be used.

A recipient MDE must be able to tell what profile is used by the sender MDE of a message and that the sending MDE location ID is self assigned by the MDE and unique.

It will be assumed that a state AOC will host all implemented profiles for all courts within a state.

Major Design Element (MDE): A logical grouping of operations representing a significant business process supported by ECF 3.0. Each MDE operation receives one or more messages, returns a synchronous response message, and optionally sends an asynchronous response message back to the original sender.

Electronic Court Filing 3.0 defines five Major Design Elements (MDEs). They are:

Filing Assembly MDE enables a filer to create a filing message for submission to a court and returns filing callback messages to the filer

Filing Review MDE enables a court to receive and review a filing message and prepare the contents for recording in its case management and document management systems and sends callback messages concerning the filing to the Filing Assembly MDE

Court Record MDE enables a court to record electronic documents and docket entries describing them in its case management and document management systems and returns a callback message to the Filing Review MDE

Service MDE enables a filer or a court to transmit filings to other parties who are participating in the case electronically who are entitled to copies of the filing

Service Registry MDE enables a filer or court to obtain the electronic and/or mail addresses of all parties in a case that must be served.

Query MDE enables a court to provide inquiry and response to other parties about case and related filing information.

Court Policy MDE enables a court to provide both design time specifications and run time information (information that will be updated from time to time [such as lists of acceptable document types, criminal charges, and civil causes of action]).



155

156157

158159160

161162

163164

165166

167

168169

170171

172

173174175

176

177

178179

180

181

182183184

185

186187

188189190

191192

193194

195196

197

198199200

15

16

Message Transmission: The sending of one or more messages and associated attachments to an MDE. Each transmission must conform to the signature of a single operation on the receiving MDE, as defined in the ECF 3.0 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 set of messages to that MDE, addressed to that operation.

Operation signature: A definition of the input message(s) and synchronous response message associated with an operation. Each input 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 3.0 specification.

2.2.2 Requirements for Designing All Messages: Note: The following requirements were used as a basis for design and review of the Electronic Court Filing 3.0 specification. This list is non-normative and not intended to be exhaustive.

A filing into an existing case will need to use the same structure for a filing initiating a new case, so that all of the metadata that may need to be changed – added, deleted, or updated – can be included along with the new document.

All metadata for an attachment includes the IANA defined mimetype, the file size, the software description, and the software version. That data has been described as base 64 encoded “insertions” rather than attachments.

The same basic structure will be used for all messages.Message Stream: The message stream is the series of bytes of data that are transmitted between major design elements (MDEs). The stream has a structure (that is, the series of bytes is organized into logical pieces or segments).

Core Message:

The core message is a series of bytes in the message stream that represent an XML document (that is, a well-formed XML data structure with a single root element); the XML document contains the following information:

Information about the message itself, such as identifiers for the sender and receiver, sending and receiving MDEs, and submission date and time; this information is called the message information

Information about each of the logical documents associated with the message; “logical” documents consist of lead documents and supporting documents, as described below

Document: A document is information about a logical document associated with the message. A logical document in this sense is the electronic representation of a single, whole, physical paper document. The document information contains two sub-structures:

Document metadata, such as the title, type, identifier, etc.

Either a “pointer” or link to the binary representations of the physical document (“representations” is plural, since a logical document may be split into several physical parts to satisfy court requirements as to maximum document size), or the encoded binary representation of the physical document embedded within the XML structure

There are two kinds of logical document: lead documents, and supporting documents.

A lead document is defined as one that will be placed on the court’s register of actions (docket). A supporting document is one that supplements the lead document; often the lead document will contain language that makes reference to a supporting document. Each supporting document is associated with one and only one “parent” lead document. This association is accomplished via the parentLeadDocumentID property on the Document class (see Review Filing domain model.)

Each filing has to have a leadDocument. A leadDocument does not have to have a supportingDocument.

Supporting documents must have a logical sequencing with respect to their parent lead document – e.g., Attachment 1, Attachment 2, Exhibit 1, Exhibit 2, etc. This sequencing is indicated by the value of the supportingDocumentSequenceIdentifier property of the Document class.

Attachment: Information transmitted between MDEs that is of an arbitrary format, and is related to the message(s) in the transmission in a manner defined in the ECF 3.0 specification. An attachment may be in XML format, non-XML text format, encoded binary format, or un-encoded binary format.

An attachment is a series of bytes in the message stream that represents the contents of all or part of a physical document. The contents are preceded by one or more “headers” that uniquely identify the attachment (via an identifier) and the format or type of the attachment. Note that the contents of an attachment can be binary octets (the “raw” binary data of the physical document), binary data encoded in text (e.g., via base-64 or some other algorithm), XML text, or plain text.

Attachments appear in the message stream after the core message. The order of attachments is unimportant and cannot be treated as significant. In particular, attachments representing the content of lead documents need not appear before attachments representing the content of supporting documents.

Within the core message, each Document structure contains one or more Attachment structures. In this way, the logical Document is associated with one or more attachments that represent the physical content of that document. Each attachment structure contains two



201202

204205206

207208209

210211212

213214

215216

217218

219

220221

222

223224

225226

227228

229

230231

232

233234235

236

237238239240

241

242243

244

245246247

248249250251

252253254

255256

17

18

properties. One property (AttachmentID) uniquely identifies the attachment; the value of this property must be the identifier that appears in the identification header preceding the attachment content in the message stream. The other property (AttachmentSequenceID) indicates the order in which this attachment is to be assembled within the context of its parent logical document. If a logical document is associated with only one attachment, then the AttachmentSequenceID will have the value 1.

Handling “embedded” attachment data:When “embedding” the contents of attachments (as defined above) within the core message structure. The Implementer MUST do so using the documentBinaryData property on the Document class.

Note: Messages that Don’t Involve Attachments

Queries Request portion of the message will NOT have attachments; however, the basic message stream structure will still work for them.

Document MetadataDocument metadata includes the following:

Document identifier – unique number identifying a whole document – including all its parts – within the context of a filing

Supporting document sequence number – indicates the order in which the filer wishes to relate this to the lead document among multiple supporting Documents associated with the same lead Document.

A filer has the option to include all of the supporting documents together with the lead document as a single document. The filer is not required to separate out the supporting documents as independent, separately identified documents. But the filer (or the Filing Assembly MDE) has this option, which in most instances will be more convenient to the filer.

documentType – is defined as the docket code used by the court’s CMS to generate the documentType text in the docket or register of actions. This clarifies that all that is transmitted is the docket code and not the text of the documentType.

The element documentDescriptiveText is used to transmit additional information to be added to the documentType text to create the docket entry.

PriorRelatedDocumentId is a reference to a previously filed document to which this document is related. For instance, Response to Motion to Dismiss is related to Plaintiff’s Motion to Strike Defendant General Motor’s Motion to Dismiss for Lack of Subject Matter Jurisdiction.

filingPartyID and filingAttorneyID(s) are court generated IDs for parties and attorneys unique to a case. A court can decide to use permanent IDs – a single ID that is assigned to a party or attorney across all cases in the court. Many courts use attorney bar number as such a permanent ID for attorneys; and there are some courts that attempt to maintain a single party record in their databases even though a party appears in many cases (so, for instance, a change in address entered once will flow through to every case in which that party appears). These IDs cannot be submitted with an initial filing unless the court generates such permanent IDs, and has generated and assigned them for all parties and attorneys in the case. One of these IDs may be the same as submitter ID; however, the submitter ID can be different from both.

The purpose of all five of these metadata items are for construction of the docket entry for a document – Response (documentType) With Additional Materials (documentDescriptiveText) filed by Attorney Able M. (filingAttorneyID) on behalf of Any Corporation, Inc. (filingPartyID) to Motion for Summary Judgment filed on behalf of Baker C. (PriorRelatedDocumentId).

Note: Metadata element or elements for document size were not created. This information should be contained as part of the description of an attachment and conveyed by the messaging profile as a nonfunctional requirement.

Containment structures involved in the message stream diagrams:



257258259260

261

262263

264265

266

267268

269

270

271272

273274275

276277

278279

280281

282283284285286287

288289290

291292

293294

19

20

The following diagram illustrates the scenario of a message stream involving two lead documents, the first of which has two supporting documents. The second lead document has no supporting documents. All four logical documents are associated with a single attachment.



295296297

298

21

22

The following diagram illustrates the scenario of 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 attachments, presumably due to limits set by the court on attachment size. Each logical lead document is associated with a single attachment; the one logical supporting document is associated with the two attachments.



299300301302

303304

23

24

2.2.2.1 MessageID ElementThe REQUIRED MessageID element is a string that identifies the parameters governing the exchange of messages between the parties. The recipient of a message MUST be able to resolve the MessageID to an individual set of parameters, taking into account the sender of the message.

The value of a MessageID element MUST be unique within a namespace.

The MessageID is constructed as a UUID. UUID stands for a Universal Unique Identifier. These are 128 bit numbers assigned to any object within a DCE cell which is guaranteed to be unique. The mechanism used to guarantee that UUIDs are Unique is through combinations of hardware addresses, time stamps and random seeds.

There is a reference in the UUID to the hardware address of the first network card on the host which generated the UUID - this reference is intended to ensure the UUID will be unique in space as the MAC address of every network card is assigned by a single global authority and is guaranteed to be unique.

This [RFC 4122] specifies 4 algorithms to generate universally unique ID's. The following subset is REQUIRED for LegalXML standards:

1. System timestamp up to a 100 nanoseconds

2. MAC address of the machine where UUID is generated

3. Use of Random or pseudo random numbers

The messaging parameters are determined by the appropriate elements from the Electronic Court Filing 3.0, as identified by the MessageID element.

If a receiver determines that a message is in conflict with the Electronic Court Filing 3.0, the appropriate handling of this conflict is undefined by this specification. Therefore, senders SHOULD NOT generate such messages unless they have prior knowledge of the receiver's capability to deal with this conflict.

If a Receiving MDE detects an inconsistency, then it MUST report it with an errorCode of Inconsistent and a severity of Error. If the MessageID is not recognized, then it MUST report it with an errorCode of Not Recognized and a severity of Error.

2.2.2.2 ConversationId Element

The REQUIRED ConversationId element is a string identifying the set of related messages that take up a conversation between two Parties. It MUST be unique within the context of the specified MessageID. The Party initiating a conversation determines the value of the ConversationId element that SHALL be reflected in all messages pertaining to that conversation.

The ConversationId enables the recipient of a message to identify the instance of an application or process that generated or handled earlier messages within a conversation. It remains constant for all messages within a conversation.

The value used for a ConversationId is implementation dependent. An example of the ConversationId element follows:

Note: Implementations are free to choose how they will identify and store conversational state related to a specific conversation. Implementations SHOULD provide a facility for mapping between their identification scheme and a ConversationId generated by another implementation

2.2.2.3 CourtID ElementCourt ID is a single element. Court Policy will define the acceptable values for a court or for a state and assign an ID to each acceptable value. The Filer will have to locate and enter the proper value for the court into which s/he wishes to submit a filing. Every state MUST create a single hierarchical structure within that state for creating a court ID, for instance, superior court Maricopa County Mesa juvenile.

2.2.2.4 Case DataThe requirement that a filing into an existing case will need to use the same structure for a filing initiating a new case, so that all of the metadata that may need to be changed – added, deleted, or updated – can be included along with the new document.

The message structure for a document initiating a new case will include two arguments – the first argument will include the information that is required to initiate a new case regardless of case type; the second argument will include data unique to each case type.

The presence of a caseTrackingID will serve as the flag for a filing into an existing case. In these cases, inclusion of the case initiation metadata will be optional. It will exist only when the filing calls for a change to any of that metadata.



305

306

307308309310

311

312313314

315316317

318319

320

321

322

323

324325326

327328329

330331

332

333334335336

337338

339

340341342

343344345346347

348349350

351352353

354355

356

25

26

Case data for the first argument includes:

Case category, case subcategory, and case type – the NCSC statistical dictionary. (Note: This will be revised)

Short case title

DocumentType element represents the docket code.

Format and application and application version will be handled through a non-functional requirement – they will be contained in the MIME content type.

Character set is defined as UTF8 and is applicable to any text in the message, XML, etc.

Party information will be shown by the case-person relationships of:

• Initiating party,

• responding party, and

• otherActorElement

Cases using the style “In re” have only one party. The specification will call for users to employ the responding party type for transmitting this information.

Case participants and their relationships to case and person objects is OPTIONAL and determined through Court Development Time Policy. The filing will not need to describe them or transmit all of the needed information.

A person-to-person relationship is available to show associations of various persons, such as parties and attorneys, which can include one to many relationships in both directions.

Attorney information will be represented by the attorneyReferenceID element.

2.2.2.5 Payment informationECF 3.0 MUST support the payment of filing fees. Additional payments of fines, restitution, etc. will be addressed in futures version of the ECF specification.

The element paymentAuthorization includes payment information that constitutes authorization for a court to use it to complete a transaction.

Note: A surcharge added to a fee to cover the costs of a credit card transaction is NOT supported at this time.

The element names and their definitions are included in the Payment Message.

2.2.3 Court PolicyECF 3.0 will provide each court with a mechanism for presenting its court-specific information in Court Policy. Court Policy will be of three types – human readable (e.g., the court’s rules), development time information (court rules governing electronic filing that are needed at the time an application is developed but which is not likely to change [e.g., whether a court will accept the filing of a URL in lieu of the document itself]), and run time information (information that will be updated from time to time [such as lists of acceptable document types, criminal charges, and civil causes of action]). The latter two forms of information will be conveyed according to a defined Court Policy message structure.

The court MUST have only one active version of human readable, development time, and run time policies at a time.

The court’s human readable, development time, and run time policy MUST have a version number and process associated with it. The versioning process SHOULD follow the prescribed rules:

Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the Policy. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards.

It is important to note that a policy that has not reached 1.0.0 is not subject to the guidelines described in this document. Before a 1.0 release (version 0.x.y), the Policy can and will be changing freely, without regard to the restrictions.

Human readable and machine readable policies MUST be released on the same date by the court.

Note: It is recommended that Court’s dispense with documents now designated as “cover sheets” in an electronic filing environment. All the data contained in a cover sheet is submitted as metadata. There is no need for that information to be submitted as an independent electronic document for retention in the court record. The data itself is made part of the Court Management Systems record.

2.2.3.1 Human Readable PolicyThe human readable court policy should set forth any instances in which a court will mandate a specific cardinality that a schema makes optional. The human readable policy also is to inform each Filer or Party to know the expectations and/or constraints placed on the data elements and other aspects of a given electronic filing system.

The human readable policy MUST define the Machine readable policies location.

The court will also define all Major Design Element names and operations supported.

The court MUST maintain all restrictions to property values in the human readable policy other than code list restrictions. (Only applicable for ECF 3.0 later versions this restriction will be removed)



357

358

359

360

361362

363

364

365

366

367

368369

370371

372373

374

375376377

378379

380

381

382383384385386387388

389

390391

392393394

395396

397

398399400

401402403404

405

406

407408

27

28

This section includes court specific information, including court identification and contact information, rules, policies, and local extension to the LegalXML Electronic Court Filing Specification. Court Policy must include Court and Rule elements.

Each court will provide its own Court Id within the human readable policy. (Note: a mechanism for searching for a court id will be readdressed in future specifications.)

The Court will MUST define a lead document through policy as the receiving court and define how it dockets matters.

2.2.3.2 Machine Readable PolicyCourt Rules define the rules for filings that the court will accept the following elements MUST be included in the schema.

Accept Document URL Indicator

Accept Documents Requiring Fee Indicator

Accept Sealed Documents Indicator

Accept Multiple Filings

Development Time Policy regarding Extensions

Extensions are allowed to this standard. All extensions shall be readily identifiable by conforming applications.

Conforming applications that do not understand the extension may ignore the extended element and its content.

Extensions shall be identified by the appearance of an underscore character, “_”, at the end of the new Element name. Following the underscore, there shall be a series of characters identifying the individual or organization creating the extension.

Court Specific Extension will include name, value, cardinality and a pointer into the XML schema structure.

The Court must provide policy for how the filingPartyID and filingAttorneyID are to be maintained during electronic communication regarding the case.

2.2.4 Encryption and SignaturesNote this area will be revised.Digital SignaturesThe alert element of a Electronic Court Filing 3.0 Message MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [XMLSIG]. Other XML signature mechanisms MUST NOT be used in Electronic Court Filing 3.0 Messages.

Processors MUST NOT reject an Electronic Court Filing 3. 0Message containing such a signature simply because they are not capable of verifying it; they MUST continue processing and MAY inform the user of their failure to validate the signature.

In other words, the presence of an element with the namespace URI [XMLSIG] and a local name of “Signature” as a child of the alert element must not cause a processor to fail merely because of its presence.

EncryptionThe alert element of a Electronic Court Filing 3.0Message MAY be encrypted, using the mechanisms described by XML Encryption Syntax and Processing [XMLENC]. Other XML encryption mechanisms MUST NOT be used in Electronic Court Filing 3.0 Messages; however, transport-layer encryption mechanisms may be used independently of this requirement.

2.2.5 Archival StorageNeeds to be addressed: Current recommendation is to follow similar strategy implemented by The U.S. National Archives and Records Administration.



409410

411412

413

414415

416

417

418

419

420421

422

423

424425

426

427428

429430

431

432433

434435

436437

438

439440441

442443444

29

30

2.2.6 Date and Time FormatIn the specifications for date and time, optional parts are denoted by square brackets (‘[‘ and ‘]’). Options may nest such that, e.g., date can be any of CCYY, CCYY-MM, or CCYY-MM-DD. Specifically, the form CCYY-DD is not allowed.

Document times and dates follow the standards set by ISO 8601 (the ISO standard for numerical date/time interchange formats). Specifically, dates shall be expressed using the Gregorian Calendar and the form “CCYY[-MM[-DD]]”. For example, “1999-01-02” represents “2 January 1999”. All components shall be zero-padded to two digits.

Times shall be expressed in local time only, using the one of the following forms:

hh[:mm[:ss[.ttt]]]-hh[:mm]

hh[:mm[:ss[.ttt]]]-hh[:mm]

hh[:mm[:ss[.ttt]]].

All components shall be zero-padded to two digits.

For example, “22:04:38.015-07” represents “thirty-eight and 15 thousands seconds after 10:04 PM Mountain Standard Time”.

Periods of time will conform to ISO 8601. Duration shall be expressed in one of the following ways:

a) As a period delimited by a specific start and end times. :

A solidus (i.e. slash, “/”) shall be used to separate the start time from the end time. Start time and end time shall conform to the ISO 8601 form shown above.

For example, “14:00/16:00” indicates a period of two hours beginning at 2:00 PM local time.

b) As a quantity, expressed as follows:

PnYnMnWnDTnHnMnS - The format is interpreted as follows: “P” introduces the string as a quantity of time, “T” introduces a time period (i.e., a number of hours, minutes, and seconds), and “n” in all uses denotes a number. “Y” denotes years, “M” denotes months, “W” denotes weeks of the year, “D” denotes days, “H” denotes hours, “M” denotes minutes, and “S” denotes seconds. The first week of a new year is the week that has the majority of its days in the New Year. All elements of the period are optional with the exception of the leading “P”.

Examples are:

“P2Y10M15DT5H12M” is a period of 2 years, 10 months, 15 days, 5 hours, and 12 minutes.

“PT2H30M” is a period of 2 hours and 30 minutes.



445

446447448

449450451

452

453

454

455

456

457

458

459

460461

462

463

464465466467468

469

470

471

31

32

3 Major Design Elements

3.1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filings to a court for review and can receive the results of that process.

This Process represents the Filer’s side of the electronic filing of documents and Filing Metadata submitted to the court electronically by means of an XML based protocol.

This Process provides an interface to human Filers to a court for review, to receive responses to those filings, and to submit requests to a Court for information and to receive responses to those requests.

A Filing Assembly MDE will often be tightly coupled with other LegalXML system Processes and third-party Processes.

A Filing MDE may be provided by a court or by a third party.

3.1.1 Filing Assembly GlossaryTerm Description

Filing Electronic document collection that has been assembled for filing on a designated court case.

Docketing The process invoked when a court receives a pleading, order, or notice, when no errors in transmission or in

presence of required content have occurred, and when the pleading, order, or notice is recorded as a part of the

official record.

Document Represents a electronic version of the paper that would have been sent as paper.

Filer Attorneys or pro se litigants are individuals who assemble and submit Filings (data and documents)

3.1.2 Filing Assembly Overview Usage Scenario

Synchronous Request/Response

Basic Callback

One Way



472

473

474

475476

477478

479480

481

482

483

484485

486

487

488

33

34

3.1.3 Filer Review Filing Callback ServiceOperations/Message Types

Operation Msg. Type

Message Parameters Type

NotifyFilingReviewComplete Input NotifyFilingReviewCompleteRequest

FilingReviewResults callback-messages:ReviewFilingCallbackMessageType

CaseTypeSpecificInformation case-type-information:CaseTypeSpecificInformationType

CourtSpecificInformation xsd:anyType

CaseInformation case-type-information:CaseInformationType

PaymentReceipt payment:FilingPayment

output NotifyFilingReviewCompleteResponse

3.1.3.1 NotifyFilingReviewCompleteDescriptionA call to this operation results in the Filing Review MDE sending a request back regarding the Filing Review Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the filing message in the final request/response. The NotifyFilingReviewCompleteRequest includes the FilingReviewResults, CaseTypeSpecificInformation, CourtSpecificInformation, CaseInformation, and optional PaymentReceipt.

ScenarioThe scenario used will be Synchronous Request/Response.

Message StyleThe rpc/literal message style will be used.

3.1.3.2 WSDL The Notify Review Filing Callback Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.

WSDL Note: The address will need to be updated with a permanent address.

Temporary Address:

http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip

SchemaNote: The address will need to be updated with a permanent address.

Temporary Address:




489490

491492

493494495496

497

498

499

500

501502503

504

505

506

507

508

509

510

511

35

36



3.2 Filing Review MDEThe Filing Review MDE receives, presents, and manages the filings. When the Filing Review MDE receives filings in a standard format/structure and presents those filings 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.

For accepted filings, the Filing Review MDE transmits data and documents to the Court Record MDE for Docketing recording of the documents.

3.2.1 Filing Review GlossaryTerm Description

Filing The set of electronic documents and associated metadata included in a submission intended to be docketed by the court. This document or collection of documents is either accepted or rejected by the court. It should be noted that, in some courts, “filing” means acceptance of a packet of associated documents. “Filing” is understood as opposed to “docketing,” which is the recording in a docket or register of actions of a filing, event, or activity that the court makes part of its official record

Docketing The process invoked when a court receives a pleading, order, or notice, when no errors in transmission or in presence of required content have occurred, and when the pleading, order, or notice is recorded as a part of the official record.

Document An XML document instance. One or more electronic pleadings or other court devices that can be contained within an XML document or XML envelope.


3.2.2 Filing Review Overview Usage Scenario


Basic Callback

One Way

3.2.3 Review Filing ServiceOperations/Message Types

Operation Msg. Type Message Parameters Type

ReviewFiling Input ReviewFilingRequest Corefiling review-filing:ReviewFilingMessageType

CaseTypeSpecificInformation

case-type-information:CaseTypeSpecificInformationType


FilingPayment payment:FilingPayment

output ReviewFilingResponse

3.2.3.1 ReviewFiling DescriptionThe Filing Review MDE sends a Filing Receipt, expressing the filing was accepted, and that the documents and other data were recorded into the court record.

A call to this operation results in the Filing Review MDE processing a request regarding the Filing Review Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the review filing message in the final request/response. The ReviewFilingRequest includes the Corefiling, CaseTypeSpecificInformation, CourtSpecificInformation, and optional FilingPayment.





512513514

515516

517518

519

520521

522

523

524

525526

527528

529530

531532533534

535

536

537

538

37

38

3.2.3.2 WSDL The Review Filing Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


3.2.4 Record Docketing Callback ServiceOperations/Message Types

Operation Msg. Type


NotifyDocketingComplete Input NotifyDocketingCompleteRequest RecordDocketingMessage record-docketing:RecordDocketingMessageType



CaseInformation case-type-information:CaseInformationType

output NotifyDocketingCompleteResponse

3.2.4.1 NotifyDocketingComplete DescriptionThe Filing Review MDE receives a Record Docketing Callback, expressing the filing was docketed, and that the documents and other data were recorded into the court record.

A call to this operation results in the Filing Review MDE processing a callback regarding the Record Docketing Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the notify docketing complete message in the final request/response. The NotifyDocketingCompleteRequest includes the RecordDocketingMessage, CaseTypeSpecificInformation, CourtSpecificInformation, and CaseInformation.



3.2.4.2 WSDL The Record Docketing Callback Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:




539540

541

542

543

544

545

546

547

548

549550

551552

553554

555556557558

559

560

561

562

563564565

566

567

568

569

570

571

572

573

574

39

40





3.3 Court Record MDEThe Court Record MDE receives, presents, and manages the filings for recording into the record. When the Court Record MDE receives filings in a standard format/structure and presents those filings to a Clerk for docketing, where they may be accepted or rejected.

The Court Record MDE transmits data and documents to the Filing Review MDE to inform the reviewer that the Filing has been accepted or rejected.

For docketed filings, the Court Record MDE transmits data and documents to the Filing Review MDE for notification of the filing’s documents have been docketed.

3.3.1 Court Record GlossaryTerm Description

Clerk Receives, indexes, and files pleadings, orders, and notices for litigants, attorneys, judges, and clerk of court. Reviews queued entries prior to docketing. Reviews pleadings, orders, and notices of individual case.




3.3.2 Court Record Overview Usage Scenario


Basic Callback

One Way

3.3.3 Record Docketing into the Court Record ServiceOperations/Message Types

Operation Msg. Type Message Parameters Type

RecordFiling Input RecordFilingRequest RecordDocketingMessage record-docketing:RecordDocketingMessageType

Corefiling review-filing:ReviewFilingMessageType

CaseTypeSpecificInformation

case-type-information:CaseTypeSpecificInformationType


output RecordFilingResponse

3.3.3.1 RecordFiling DescriptionThe Court Record MDE receives a Record Filing, expressing the filing is to be docketed, and that the documents and other data are ready to be processed into the court record.

A call to this operation results in the Court Record MDE processing a message regarding the Record Docketing Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the record filing message in the final request/response. The NotifyDocketingCompleteRequest includes the RecordDocketingMessage, Corefiling, CaseTypeSpecificInformation, and CourtSpecificInformation.





575576577

578579

580581

582

583584

585

586

587

588589

590591

592593

594595596597

598

599

600

601

41

42

3.3.3.2 WSDL The Record Docketing Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


3.4 Service MDEThe Service MDE enables a filer or a court to transmit filings to other parties who are participating in the case electronically who are entitled to copies of the filing.

The Service MDE transmits data and documents to the Filing Assembly MDE to inform the case participant that the Filing has been made with the court.

For docketed filings, the Service MDE transmits data and documents only to the Filing Assembly MDE for notification to the case participant.

3.4.1 Service GlossaryTerm Description

Service The performance of secondary service is notification to a case participant that a filing has been made.

Court An official, lawful authority to adjudicate disputes, and to dispense civil, labor, administrative and criminal justice under the law.



Case Participant May be any person for whom a court wishes to establish a substantive communication because of his/her importance to the case.

3.4.2 Service Overview Usage Scenario


Basic Callback

One Way

3.4.3 Serve Filing ServiceOperations/Message Types

Operation Msg. Type


Servefiling Input ServefilingRequest Corefiling review-filing:ReviewFilingMessageType



output ServefilingResponse

3.4.3.1 Servefiling Description



602603

604

605

606

607

608

609

610

611

612613614

615616

617

618

619620

621

622

623

624625

626627

43

44



The Service MDE receives a Filing for service, expressing the filing is to be served, and that the documents and other data are ready to be processed.

A call to this operation results in the Serve MDE processing a message regarding the Filing Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the serve filing message in the final request/response. The ServefilingRequest includes the Corefiling, CaseTypeSpecificInformation, and CourtSpecificInformation.



3.4.3.2 WSDL The Serve Filing Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


3.5 Service Registry MDEThe Service Registry MDE enables a filer or court to obtain the electronic and/or mail addresses of all parties in a case that must be served..

The Service Registry MDE transmits service address information to the Filing Assembly MDE to inform the filer for whom he/she may serve electronically.

The Service Registry MDE transmits data about know case participants service information for a specific case.

3.5.1 Service Registry GlossaryTerm Description

Service The performance of secondary service is notification to a case participant that a filing has been made.





3.5.2 Service Registry Overview Usage Scenario


Basic Callback

One Way

3.5.3 Get Service Registry InformationOperations/Message Types

Operation Msg. Type




628629

630631632

633

634

635

636

637638

639

640

641

642

643

644

645

646

647648

649650

651

652

653654

655

656

657

658659

45

46



GetServiceInformation Input GetServiceInformationRequest ServiceInformationQueryMessage query:ServiceInformationQueryMessageType

output GetServiceInformationResponse

3.5.3.1 GetServiceInformation DescriptionThe Service MDE receives a Filing for service, expressing the filing is to be served, and that the documents and other data are ready to be processed.

A call to this operation results in the Serve MDE processing a message regarding the Filing Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the serve registry information message in the final request/response. The ServefilingRequest includes the Corefiling, CaseTypeSpecificInformation, and CourtSpecificInformation.



3.5.3.2 WSDL The Get Service Registry Information Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


3.6 Query MDEThe Query enables a court to provide inquiry and response to other parties about case and related filing information.

The Query MDE transmits data and documents to the Filing Assembly MDE to inform the requesting MDE the requested information.

For accepted queries, the Query MDE transmits data and documents to the Filing Assembly MDE.

3.6.1 Query GlossaryTerm Description





Clerk Receives, indexes, and files pleadings, orders, and notices for litigants, attorneys, judges, and clerk of court. Reviews queued entries prior to docketing. Reviews pleadings, orders, and notices of individual case.





660661

662663

664665666

667

668

669

670

671

672673674

675

676

677

678

679

680

681

682

683684

685

686

687

47

48



3.6.2 Query Overview Usage Scenario


3.6.3 Calculate FeesOperations/Message Types

Operation Msg. Type


GetCalculatedFee Input GetCalculatedFeesRequest CalculatedFeesQueryMessage

query:CalculatedFeesQueryMessageType

output GetCalculatedFeesResponse

3.6.3.1 GetCalculatedFee DescriptionThe Query MDE receives a Filing for fee calculation, expressing the filing’s lead document, supporting documents, and other date are ready to be used in calculating filing fees.

A call to this operation results in the Query MDE processing a message regarding the Calculate Fee Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the serve filing message in the final request/response. The GetCalculatedFeesRequest includes the CalculatedFeesQueryMessage.



3.6.3.2 WSDL The Calculate Fees Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


3.6.4 Case List ServiceOperations/Message Types

Operation Msg. Type


GetCaseList Input GetCaseListRequest CaseListQueryMessage query:CaseListQueryMessageType

output GetCaseListResponse

3.6.4.1 GetCaseList DescriptionThe Query MDE receives a request for to query the courts records for a list of cases based on provided criteria.



688689

690

691692

693694

695696

697698699

700

701

702

703

704705

706

707

708

709

710

711

712

713

714

715716

717718

719

49

50



A call to this operation results in the Query MDE processing a message regarding the list of cases meeting the case list criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the case list message in the final request/response. The GetCaseList includes the CaseListQueryMessage.



3.6.4.2 WSDL The Case List Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


3.6.5 Case ServiceOperations/Message Types

Operation Msg. Type


GetCase Input GetCaseRequest CaseQueryMessage query:CaseQueryMessageType

output GetCaseResponse

3.6.5.1 GetCaseDescriptionThe Query MDE receives a request for to query the courts records for a case based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding the case meeting the case criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the case message in the final request/response. The GetCase includes the CaseQueryMessage.



3.6.5.2 WSDL The Case Service Fees Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:





720721722

723724

725

726

727

728729

730

731

732

733

734

735

736

737

738

739740

741742

743

744745746

747748

749

750

751

752753

754

755

756

757

758

759

51

52




Temporary Address:


3.6.6 Document ServiceOperations/Message Types

Operation Msg. Type


GetDocument Input GetDocumentRequest DocumentQueryMessage query:DocumentQueryMessageType

output GetDocumentResponse

3.6.6.1 GetDocumentDescriptionThe Query MDE receives a request for to query the courts records for a case’s document based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding the document meeting the document criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the document message in the final request/response. The GetDocument includes the DocumentQueryMessage.



3.6.6.2 WSDL The Document Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


3.6.7 Filing List ServiceOperations/Message Types

Operation Msg. Type


GetFilingList Input GetFilingListRequest FilingListQueryMessage query:FilingListQueryMessageType

output GetFilingListResponse

3.6.7.1 GetFilingListDescriptionThe Query MDE receives a request for to query the courts records for a list of filings based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding the filing list meeting the filing and case criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the filing list message in the final request/response. The GetFilingList includes the FilingListQueryMessage.



760

761

762

763

764765

766767

768

769770771

772773

774

775

776

777778

779

780

781

782

783

784

785

786

787788

789790

791

792793794

53

54






3.6.7.2 WSDL The Filing List Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


3.6.8 Filing ServiceOperations/Message Types

Operation Msg. Type


GetFiling Input GetFilingRequest FilingQueryMessage query:FilingQueryMessageType

output GetFilingResponse

3.6.8.1 GetFilingDescriptionThe Query MDE receives a request for to query the courts records for a case’s filing based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding a filing meeting the filing and case criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the filing message in the final request/response. The GetFiling includes the FilingQueryMessage.



3.6.8.2 WSDL The Filing Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:




795

796

797

798

799800

801

802

803

804

805

806

807

808

809810

811812

813

814815816

817818

819

820

821

822823

824

825

826

827

828

829

830

831

55

56





3.6.9 Filing Status ServiceOperations/Message Types

Operation Msg. Type


GetFilingStatus Input GetFilingStatusRequest FilingStatusQueryMessage query:FilingStatusQueryMessageType

output GetFilingStatusResponse

3.6.9.1 GetFilingStatusDescriptionThe Query MDE receives a request for to query the courts records for a case’s filing status based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding a filing status meeting the filing and case criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the filing status message in the final request/response. The GetFilingStatus includes the FilingStatusQueryMessage.



3.6.9.2 WSDL The Filing Status Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:




832

833834

835836

837

838839840

841842

843

844

845

846847

848

849

850

851

852

853

854

855

856

857

57

58



3.7 Court Policy MDEThe Court Policy MDE receives, presents, and manages the machine readable policies. When the Court Policy MDE receives a request in a standard format/structure and presents those policies back to the requesting MDE.

The Court Policy MDE transmits data and documents to the requesting MDE to inform the requestor that the policies and code values.

3.7.1 Court Policy GlossaryTerm Description

Machine Readable Policies Expressed as XML message and structure symbolizing the development time information (court rules governing electronic filing that are needed at the time an application is developed but which is not likely to change [e.g., whether a court will accept the filing of a URL in lieu of the document itself]), and run time information (information that will be updated from time to time [such as lists of acceptable document types, criminal charges, and civil causes of action])

3.7.2 Court Policy Overview Usage Scenario

Asynchronous Request/Response

3.7.3 Court Policy ServiceOperations/Message Types

Operation Msg. Type


GetPolicy Input GetPolicyRequest CourtID jxdm:IDType

output GetPolicyResponse

3.7.3.1 GetPolicyDescriptionThe Court Policy MDE receives a request for to query the courts machine readable policies based on provided criteria.

A call to this operation results in the Court Policy MDE processing a message regarding a policy meeting the courts policy message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the court policy message in the final request/response. The GetPolicyRequest includes the CourtID.



3.7.3.2 WSDL The Court Policy Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:




858859860

861

862

863864

865

866867

868

869870

871

872873874

875

876

877

878

879880

881

882

883

884

885

886

887

888

59

60



4 Message Types4.1 ReviewFilingMessageTypeThe review filing message will have synchronous and asynchronous responses. The synchronous response will be sent upon receipt of the message to indicate that it has been transmitted successfully. The asynchronous response will indicate the action taken by the court during the filing review process on the documents transmitted with the message.

The structure of a Filing including will be documented in this section. This describes the filing transaction between the Filing Assembly MDE and the Filing Review MDE. This information will become part of the Record Docketing between the Filing Review MDE and the Court Record MDE but does not necessarily describe the information that is actually stored in the Court Record.

This information will lead directly to schemas that define the standard acceptable structures in the Core Profile.

4.1.1.1 Review Filing Domain Model



889

890891892893

894895896

897

898

899

61

62

4.1.1.2 Review Filing Data DictionaryClass Property or Reference Definition and Notes

AddressType 1) Definition needed.

2) Path: AddressType

BaseMessage 1) Definition needed.

2) Path: SubmissionType

submissionDate 1) The date the Message left the control of the Filer

2) MANDATORY ELEMENT. Minimum occurrence is once and Maximum occurrence is once. (1,1)

3) Path: Submission/SubmissionDate

4) Refer to section 2.4.4 Date and Time Format for Date Format.

submissionTime 1) The time the Message left the control of the Filer


3) Path: Submission/SubmissionTime

submitterID 1) A unique identifier assigned by the filing assembly MDE for the person who is managing the interface between the filer and the filing assembly MDE. This person will receive secondary service on behalf of the filer. This is also the serviceRecipientID for subsequent filings in this case, and asynchronous responses to this filing.


3) Path: Submission/SubmissionSubmitterID/ID

4) Additional Notes: implement as choice in schema; definition change should be proposed

sendingMDELocationID 1) Location for the MDE to which asynchronous and service messages can be sent. This unique location is self-assigned by the MDE.


3) Path: Submission/SendingMDELocationID/ID

sendingMDEProfileCode 1) Code identifying the message profile being used by the sending filing assembly MDE. This list should be extensible to accommodate future messaging profiles. Each code value is specified within the message profile approved for use with ECF 3.0.


3) Path: Submission/SendingMDEProfileCode

4) NOTE: Address Location of Code Values To Be Defined.

filingID 1) An identifier for a single electronic filing transaction. "Transaction" means the sequence of messages from initial filing review through receipt of the asynchronous review callback.


3) Path: Submission/ActivityID/ID

Court 1) Definition needed.

2) Path: Submission/ActivityCourt



900

63

64

Class Property or Reference Definition and Notes

Case 1) Information needed to initiate a court case. The presence of caseTrackingIdentifier is the indicator of whether this is an existing case (present) or new case (absent). For existing cases, caseTrackingIdentifier and shortCaseTitle are mandatory; caseCategory, caseSubCategory, and caseType are not allowed. For new cases, shortCaseTitle, caseCategory, caseSubCategory, and caseType are mandatory; caseTrackingIdentifier is not allowed.

2) Path: CaseType

shortCaseTitle 1) An official name of a Case. No title exists when the message is initiating a new case.


3) Path: Case/CaseTitleText

caseCategoryCode 1) NCSC term--get definition


3) Path: Case/CaseClassification/CaseCategoryText


caseTrackingIdentifier 1) Court's case number.


3) Path: Case/CaseTrackingID/ID

caseSubCategoryCode 1) NCSC term--get definition.


3) Path: Case/CaseClassification/CaseSubCategoryText


caseTypeCode 1) NCSC term--get definition.


3) Path: Case/CaseClassification/CaseTypeCode


languageCode 1) The language of the case (used, e.g., in Canada to determine in which language the case will be conducted.) Allowable values to be set forth in court policy.

2) OPTIONAL ELEMENT. Minimum occurrence is zero and Maximum occurrence is many. (0,1)

3) Path: Case/CaseLanguageCode


RelatedCase 1) Definition needed.

2) OPTIONAL ELEMENT. Minimum occurrence is zero and Maximum occurrence is many. (0,*)

3) Path: Case/CaseRelatedCase

Organization (initiatingParty) 1) An organization that brings charges or a suit against another in a court of law. Can be either the state in a criminal case,an organizational or institutional plaintiff or petitioner in a civil case.


3) Path: Case/CaseParticipants/CaseInitiatingParty.Organization



65

66


Person (initiatingParty) 1) A person who files a lawsuit against another in a court of law. Can be either a victim in a criminal case (in a state where an individual may bring criminal charges against another) or a plaintiff or petitioner in a civil case.


3) Path: Case/CaseParticipants/CaseInitiatingParty.Person

Property (respondentParty) 1) The property in an “in rem” court case against which a claim is made.


3) Path: Case/CaseParticipants/CaseRespondentParty.Property

Organization (respondentParty) 1) The organization in a court case that is required to answer a complaint or petition for a court order or judgment or a writ requiring it to take some action, halt an activity or obey a court's direction. In an appeal, the party who must respond to an appeal initiated by a party seeking to overturn the trial court decision in whole or in part (called "appellant") in the appellate court. The accused in a domestic violence case or criminal action.


3) Path: Case/CaseParticipants/CaseRespondentParty.Organization

Person (respondentParty) 1) The person in a court case that is required to answer a complaint or petition for a court order or judgment or a writ requiring him/her to take some action, halt an activity or obey a court's direction. In an appeal, the party who must respond to an appeal initiated by a party seeking to overturn the trial court decision in whole or in part (called "appellant") in the appellate court. The accused in a domestic violence case or criminal action.


3) Path: Case/CaseParticipants/CaseRespondentParty.Person

Person (respondentPartyAttorney) 1) Definition needed.


3) Path: Case/CaseParticipants/CaseRespondentPartyAttorney

Person (initiatingPartyAttorney) 1) Definition needed.


3) Path: Case/CaseParticipants/CaseInitiatingPartyAttorney

Organization (otherActor) 1) A miscellaneous organization involved in a court case.


3) Path: Case/CaseParticipants/CaseOtherActor.Organization

Person (otherActor) 1) A miscellaneous person involved in a court case. Also, used to contain information about the parent(s) of a juvenile party in a juvenile case. Examples: caseworker, probation officer, bail bondsman, interested person, arresting officer.


3) Path: Case/CaseParticipants/CaseOtherActor.Person



67

68


PersonRelationship 1) Definition needed.


3) Path: Case/CasePersonRelationship

4) Additional Notes: of PersonRelationshipType

PersonOrganizationRelationship 1) Definition needed.


3) Path: Case/CasePersonOrganizationRelationship

OrganizationRelationship 1) Definition needed.


3) Path: Case/CaseOrganizationRelationship

CaseOrigin 1) Definition needed.


3) Path: Case/CaseLineageCase

CasePersonRole 1) Definition needed.


3) Path: Case/CasePersonRole

CaseOrganizationRole 1) Definition needed.


3) Path: Case/CaseOrganizationRole

Person (otherParty) 1) A person who is a party whose role is neither initiating nor responding party. Examples: intervenor, guardian ad litem, heir, beneficiary (e.g., of a trust), friend of court, interested party, CASA (court appointed special advocate).


3) Path: Case/CaseOtherParty.Person

Person (otherPartyAttorney) 1) Attorney representing an "other party" in this case.


3) Path: Case/CaseOtherPartyAttorney

Organization (otherParty) 1) An organization that is a party whose role is neither initiating nor responding party. Examples: intervenor, guardian ad litem.


3) Path: Case/CaseOtherParty.Organization

CaseAttorneyRole 1) Definition needed.


3) Path: Case/CaseAttorneyRole

Alias 1) Definition needed.


3) Path: Case/CaseAlias



69

70


CaseAttorneyRole 1) The role played by an attorney in this case.

2) Path: CaseAttorneyRoleType

roleCode 1) Description of the role played by an attorney in this case. Allowable values set forth in Court Policy. Examples: lead attorney.

2) MANDATORY ELEMENT. Minimum occurrence is once and Maximum occurrence is many. (1,*)

3) Path: CaseAttorneyRole/CaseAttorneyRoleCode


Person 1) Definition needed.

2) Path: CaseAttorneyRole/PersonReference

CaseOrganizationRole 1) A description of the specific role played by one or more of the organization "other actor(s)" involved in the case.

2) Path: CaseOrganizationRoleType



3) Path: CaseOrganizationRole/CaseOrganizationRoleCode


Organization 1) Definition needed.


3) Path: CaseOrganizationRole/OrganizationReference

CaseOrigin 1) The prior court, police, or prosecutor case from which this case originates. Examples: case appealed to this court from a lower court; case transferred to or removed to this court; case remanded to this court; original proceeding in this court; in some courts, a designation that this case is a reopening of a proceeding in the same court. In the criminal and juvenile delinquency contexts a police incident report number, a prosecution case number, a grand jury case number, or a criminal case bound over to this court for trial from a limited jurisdiction court.

2) Path: CaseType



3) Path: CaseLineageCase/CaseTrackingID/ID

originTypeCode 1) Type of origin. Allowable values to be set forth in Court Policy.


3) Path: CaseLineageCase/CaseOriginTypeCode


originatingOrganizationName 1) Name of organization in which the case originated. Organization ID is not used here, because the organization may not be a participant in electronic filing .


3) Path: CaseLineageCase/CaseOriginatingOrganization/OrganizationName

CasePersonRole 1) A description of the specific role played by one or more of the person "other actor(s)" or "other party(s)" involved in the case.

2) Path: CasePersonRoleType



71

72




3) Path: CasePersonRole/CasePersonRoleCode




3) Path: CasePersonRole/PersonReference

ContactInformation 1) Definition needed.

2) Path: ContactInformationType

Court 1) Definition needed.

2) Path: CourtType

courtID 1) A unique identifier for the court in which the filing is made.


3) Path: Court/OrganizationID/ID

Document 1) The pleading, motion or order that is the main document in a Filing. A Document may have Attachments.

2) Path: DocumentType

documentBinaryData 1) Embedded document data, in an encoded form acceptable to be included within XML.


3) Path: Document/DocumentBinary

4) Additional Notes: Decide how much of BinaryType structure to include (TC)

DocumentMetadata 1) Definition needed.


3) Path: Document/DocumentDescriptiveMetadata

DocumentMetadata 1) Document descriptors (title, type description, etc.) for the Document. This is meant to include all the information about the document that is needed to index it into the Case Management System and enter it into the Document Management System.

2) Path: DocumentDescriptiveMetadataType

documentIdentifier 1) A unique identifier for the document within this message. This is the identifier for a "whole" document (if that document is split into parts).


3) Path: DocumentDescriptiveMetadata/DocumentID/ID

supportingDocumentSequenceNumber 1) Indicates the order (assigned by the filer) of the supporting document within the context of its parent lead document.


3) Path: DocumentDescriptiveMetadata/DocumentSequenceID/ID



73

74


documentTypeCode 1) Optional Argument: Formal title of the document, as assigned by court rules or practice and as defined in court policy. Should be docket code used by court.


3) Path: DocumentDescriptiveMetadata/RegisterActionDescriptionText


parentDocumentIdentifier 1) Only present for supporting documents; indicates the identifier of the corresponding lead document.


3) Path: DocumentDescriptiveMetadata/ParentDocumentID/ID

language 1) The language in which the document is written.


3) Path: DocumentDescriptiveMetadata/DocumentLanguageCode

4) Additional Notes: need to choose which codelist

priorRelatedDocumentIdentifier 1) An identifier of a related document that was previously filed in this case. For instance, the document to which this document is a response.


3) Path: DocumentDescriptiveMetadata/PriorRelatedDocumentIdentifier

documentDescription 1) Name of document given by filer. Intended to supplement what is contained in the document type identifier property.


3) Path: DocumentDescriptiveMetadata/DocumentDescriptionText

filingAttorneyIdentifier 1) Identifier recognized by the court as being unique within this case, and used to identify the attorney who is filing this document. Not present for pro se litigants.


3) Path: DocumentDescriptiveMetadata/FilingAttorneyIdentifier

filingPartyIdentifier 1) Identifier recognized by the court as being unique within this case, and used to identify the party on whose behalf this document is being filed.


3) Path: DocumentDescriptiveMetadata/FilingPartyIdentifier

documentContentTypeCode 1) IANA MIME type specifying the format of the attachment. Example: application/msword; application/PDF.


3) Path: Document/DocumentBinary/BinaryFomatText




75

76


fileSize 1) Size of file expressed in bytes.


3) Path: Document/DocumentBinary/BinarySizeValue

documentProducerDescriptionText 1) Application and version used to create the document. Optional attribute.


3) Path: DocumentDescriptiveMetadata/DocumentApplicationName

AttachmentMetadata 1) Definition needed.


3) Path: DocumentDescriptiveMetadata/DocumentAttachment

4) Additional Notes: of DocumentAttachmentType

AttachmentMetadata 1) Need a definition.


3) Path: DocumentAttachmentType

attachmentID 1) A unique identifier (such as a URI) for the attachment in the message stream. (For the Web Services profile, this will be the value of the MIME Content-Id header.) Can contain a URL if the attachment is remote, if allowed by court policy.


3) Path: DocumentAttachment/AttachmentID/ID

attachmentSequenceNumber 1) A numeric sequence number used for splitting documents across multiple parts.


3) Path: DocumentAttachment/AttachmentSequenceID/ID

ElectronicFilingMessage 1) Definition needed.

2) Path: ElectronicFilingMessageType

ServiceRecipient 1) Element and Definition Undefined


IDType 1) Definition needed.

2) Path: IDType

NameType 1) Definition needed.

2) Path: PersonNameType


2) Path: OrganizationType

organizationID 1) The unique identifier assigned by the court at the time the organization is first associated with the case. If the court has not yet assigned an identifier in this case, then the filing assembly MDE will leave this blank.


3) Path: Organization/OrganizationID/ID



77

78


name 1) Definition needed.


3) Path: Organization/OrganizationName



3) Path: Organization/OrganizationPrimaryContact

4) Additional Notes: GJXDM definition is broken. refers to individual

ElectronicServiceInformation 1) Definition needed.


Alias 1) Definition needed.

2) Path: AliasType

alternateName 1) An alternative name by which this organization is known.


3) Path: Alias/AlternateNameText

alternateNameTypeCode 1) A description of the type of the alternate name. Allowable values set forth in Court Policy. Examples: doing business as, formerly known as, also known as.


3) Path: Alias/AlternateNameTypeCode




3) Path: Alias/AliasedPerson

4) Additional Notes: implement as a reference, choice with Organization



3) Path: Alias/AliasedOrganization

4) Additional Notes: implement as a reference, choice with Person



79

80


OrganizationRelationship 1) Definition needed.

2) Path: OrganizationRelationshipType

typeCode 1) Definition needed.


3) Path: OrganizationRelationship/OrganizationRelationshipTypeCode



2) Court Policy will set Element's Minimum occurrence and Maximum occurrence. (2,*)

3) Path: OrganizationRelationship/RelatedOrganization


2) Path: PersonType

personID 1) The unique identifier assigned by the court at the time the person is first associated with the case. If the court has not yet assigned an identifier in this case, then the filing assembly MDE will leave this blank.


3) Path: Person/PersonAssignedIDDetails/PersonOtherID/ID

4) Additional Notes: decided not to use the attribute, since that should be reserved for references

name 1) Definition needed.


3) Path: Person/PersonName

title 1) Person's organizational position or title.


3) Path: Person/PersonTitleText

4) Additional Notes: not using EmploymentPositionName because that is a "job description," and we want an official title (designation of office…e.g., US Atty, US Atty General, Governor, Land Commissioner, Legislator, school board member, mayor, etc.)



81

82


interpreterLanguageCode 1) A code identifying the person's native or primary language, the one the person is most comfortable using.


3) Path: Person/PersonSocialDetails/PersonPrimaryLanguageCode.iso639-2b




3) Path: Person/PrimaryContactInformation

4) Additional Notes: note in spec that this is the address where person wants service

ElectronicServiceInformation 1) Definition needed.


PersonOrganizationRelationship 1) Definition needed.

2) Path: PersonOrganizationRelationshipType



3) Path: PersonOrganizationRelationship/PersonOrganizationRelationshipTypeCode




3) Path: PersonOrganizationRelationship/RelatedPerson

4) Additional Notes: implement as references



3) Path: PersonOrganizationRelationship/RelatedOrganization




83

84


PersonRelationship 1) Definition needed.

2) Path: PersonRelationshipType

3) Additional Notes: extends RelationshipType



3) Path: PersonRelationship/PersonRelationshipTypeCode



2) Court Policy will set Element's Minimum occurrence and Maximum occurrence. (2,*)

3) Path: PersonRelationship/RelatedPerson


PhoneNumberType 1) Definition needed.

2) Path: TelephoneNumberType

Property 1) Definition needed.

2) Path: PropertyType

propertyID 1) The unique identifier assigned by the court at the time the property is first associated with the case. If the court has not yet assigned an identifier in this case, then the filing assembly MDE will leave this blank.


3) Path: Property/PropertyAssignedIDDetails/PropertyOtherID/ID

description 1) Definition needed.

2) Path: Property/PropertyDescriptionText

RelatedCase 1) Case or cases sharing characteristics, such as common parties or events, with this case.

2) Path: CaseType






85

86


associationTypeCode 1) Nature of the relationship between the current case and the related case. Allowable values to be set forth in Court Policy. Examples: associated, consolidated, related.


3) Path: Case/CaseAssociationTypeCode


courtName 1) Name of court in which the related case was filed. CourtID is not used here, because the court may not be a participant in electronic filing .


3) Path: Case/CaseCourt/OrganizationName

4) Additional Notes: needs definitional change: change tried to filed

ReviewFilingMessage 1) The structure of a Filing including any Payment Information will be documented in this section. This describes the filing transaction between the Filing Assembly MDE and the Filing Review MDE. This information will become part of the Record Docketing between the Filing Review MDE and the Court Record MDE but does not necessarily describe the information that is actually stored in the Court Record.


confidentialityIndicator 1) Indicator by the filer that something in the message requires sensitive or confidential treatment. (This replaces the former "request to seal" document metadata.)


3) Path: Submission/SubmissionConfidentialityIndicator

Document (leadDocument) 1) Sub Element and Definition Needed


3) Path: Submission/SubmissionDocument

Document (supportingDocument) 1) A document included in a Filing that supports the Document. This document is not separately entered on the docket or register of actions.


3) Path: Submission/SubmissionSupportingDocument



87

88


Case 1) Definition needed.


3) Path: Submission/SubmissionCase

ElectronicServiceInformation 1) Information provided by the filing assembly MDE to the court identifying the persons being served electronically with a copy of this document. This information can constitute the certificate of service for service performed electronically. This information is also provided by the filing assembly MDE to service MDEs to identify persons to whom the service MDEs is required to deliver the filing.

2) Path: ServiceRecipientType

serviceRecipientID 1) A unique identifier assigned by the filing assembly MDE for the person who is managing the interface between the filer and the filing assembly MDE. This person will receive secondary service on behalf of the filer. This is also the submitterID for filings in this case, and asynchronous responses to filings.


3) Path: ServiceRecipient/ServiceRecipientID/ID

receivingMDELocationID 1) The location of the filing assembly MDE associated with the person receiving service.


3) Path: ServiceRecipient/ReceivingMDELocationID/ID

receivingMDEProfileCode 1) Code identifying the message profile being used by the receiving filing assembly MDE. This list should be extensible to accommodate future messaging profiles. Each code value is specified within the message profile approved for use with ECF 3.0.


3) Path: ServiceRecipient/ReceivingMDEProfileCodeText


Text 1) Definition needed.

2) Path: TextType

binary 1) Definition needed.

2) Path: BinaryType



901

89

90

4.2 ReviewFilingCallbackMessageTypeThe structure of a Review Filing callback will be documented in this section. This describes the callback transaction between the Filing Assembly MDE and the Filing Review MDE. This information will serve as the outcome to Review Filing Message previously provided.

The asynchronous response will indicate the action taken by the court during the filing review process on the documents transmitted with the message.


4.2.1.1 Review Filing Callback Domain Model



902

903904905

906907

908

909

910

91

92

4.2.1.2 Review Filing Callback Data Dictionary


CallbackMessage 1) Definition needed.


receivedDate 1) The date the Record Docketing Message left the control of the Filing Review.


3) Path: Submission/SubmissionReceivedDate


receivedTime 1) The time the Record Docketing Message left the control of the Filing Review.


3) Path: Submission/SubmissionReceivedTime

MessageReceiptMessage 1) A message returned synchronously to indicate receipt by an MDE of another message. The name "MessageReceipt" suggested by S. Durham June 30 2005, and adopted by consensus on a TC call that day. The intent is that this will serve as the synchronous reply to all MDE operations that have an additional, asynchronous callback.

2) Path: MessageReceiptMessageType

originalMessageID 1) The identifier, assigned by the messaging profile in effect, to the original message sent to the MDE that prompted the return of this receipt.


3) Path: MessageReceiptMessage/OriginalMessageID/ID

4) Additional Notes: OriginalMessageID of IDType

originalMessageReceiptDate 1) Date on which the original message was received at the MDE, on the MDE's clock.


3) Path: MessageReceiptMessage/OriginalMessageReceiptDate


originalMessageReceiptTime 1) Time at which the original message was received at the MDE, on the MDE's clock.


3) Path: MessageReceiptMessage/OriginalMessageReceiptTime



911

912

93

94


Error 1) Representation of an error that occurred when synchronously processing the message.

2) OPTIONAL ELEMENT. Minimum occurrence is zero and Maximum occurrence is many. (0,*) This will control sub elements.

3) Path: ErrorType

errorCode 1) A code that uniquely identifies an error. Allowable values set forth in court policy.


3) Path: Error/ErrorCode


errorDescription 1) A more "user friendly" description of the error.


3) Path: Error/ErrorDescriptionText

4) Additional Notes: of TextType

ElectronicFilingCallbackMessage 1) Definition needed.

2) Path: ElectronicFilingCallbackMessageType

3) Additional Notes: extends SubmissionType

filingStatusCode 1) Status of the filing as determined by the system sending the callback. Values: accepted, partially accepted (e.g., some documents but not others), rejected.


3) Path: ElectronicFilingCallbackMessage/FilingStatusCode


filingStatusReasonDescription 1) A textual description of the reason for the setting of the status in the filingStatusCode.


3) Path: ElectronicFilingCallbackMessage/FilingStatusReasonDescription


ReviewedDocument 1) This association will be present for every document that is reviewed by clerk review. For documents that were rejected by the clerk review process or the court record system, only the documentStatusCode, originalDocumentID, and (optionally) the documentStatusReasonDescription will be present. For documents that were accepted and recorded, all attributes will be present, except for documentStatusReasonDescription, which may or may not be present.


3) Path: ElectronicFilingCallbackMessage/ReviewedDocument

4) Additional Notes: of ReviewedDocumentType

DocketedCase 1) This association will always be present, except in the situation where the filing was a case initiation filing and was rejected (therefore, no case was initiated in the court record system.)


3) Path: ElectronicFilingCallbackMessage/DocketedCase

4) Additional Notes: of CaseType



95

96


DocketedCase 1) A case that has been initiated in the court record system.

2) Path: CaseType

caseTrackingID 1) Definition needed.



ReviewedDocument 1) A document that has been reviewed through the clerk review process, and that potentially has been or will be recorded in the court record system.

2) Path: ReviewedDocumentType

3) Additional Notes: extends DocumentType

documentStatusCode 1) Code to describe the disposition of the document: accepted or rejected. Allowable values defined in the specification (schema).


3) Path: ReviewedDocument/DocumentDescriptiveMetadata/DocumentStatus/StatusText


documentHash 1) A hash of the document as it appears in the court record. This attribute will be populated by either the clerk review process or the court record system. If the latter, then it will be absent in the RecordDocketingMessage. It will also be absent in callbacks for rejected documents.


3) Path: ReviewedDocument/DocumentHashText


documentStatusReasonDescription 1) A textual description of the reason for the setting of the status in the documentStatusCode.


3) Path: ReviewedDocument/DocumentDescriptiveMetadata/DocumentStatus/StatusDescriptionText

originalDocumentID 1) The identifier for this document in the original ReviewFilingMessage structure. This is provided to link each filed document to a docketed document identifier in the court record.


3) Path: ReviewedDocument/DocumentDescriptiveMetadata/DocumentID/ID



97

98


documentDocketID 1) The identifier from the court record system used to identify the document. This attribute is populated by the MDE/process that is authorized to create docket identifiers; the attribute will not be present before that creation takes place. For example, if the clerk review process creates docket identifiers, then this attribute will be present in the RecordDocketingMessage that goes to the court record MDE. However, if the court record process creates docket identifiers, then this attribute will not be present in the RecordDocketingMessage, but will be present in subsequent callbacks. This attribute will be absent in callbacks when the ReviewedDocument was rejected, either by clerk review or the court record system.


3) Path: ReviewedDocument/DocumentDocketID/ID

4) Additional Notes: DocumentDocketID of IDType

sealDocumentIndicator 1) Clerk's instruction to court record system to seal this document.


3) Path: ReviewedDocument/SealDocumentIndicator

4) Additional Notes: of type j-xsd: Boolean



913

914

99

100

4.3 RecordDocketingMessageTypeThe structure of a Record Docketing Message will be documented in this section. This describes the Record Docketing transaction between the Filing Review MDE and the Court Record MDE. This information will become part of the Record Docketing Callback between the Court Record MDE and the Filing Review MDE but does not necessarily describe the information that is actually stored in the Court Record.

The synchronous response will indicate the action taken by the court during the recording process on the documents transmitted with the review filing message.


4.3.1.1 Record Docketing Domain Model

Note: ReviewedDocument mapped in CallbackMessage



915

916917918919

920921

922

923

924

925926927

101

102

4.3.1.2 Record Docketing Data Dictionary

























928

929

930

103

104






RecordDocketingMessage 1) Message resulting from clerk review and edit of a ReviewFilingMessage.

2) Path: RecordDocketingMessageType


sealCaseIndicator 1) Instruction from the clerk to the court record to represent this case as "sealed."


3) Path: RecordDocketingMessage/SealCaseIndicator




3) Path: RecordDocketingMessage/CaseTrackingID/ID

reviewComments 1) Comments provided by the clerk to the court record system during review.


3) Path: RecordDocketingMessage/FilingReviewCommentsText

reviewFilingMessageReceiptDate 1) The date at which the Filing Review MDE received the filing. This could be the same as, but no earlier than, the ReviewFilingMessage.submissionDate.


3) Path: RecordDocketingMessage/ReviewFilingMessageReceiptDate


reviewFilingMessageReceiptTime 1) The time at which the Filing Review MDE received the filing. When combined with the reviewFilingMessageReceiptDate, this time should be no earlier than the ReviewFilingMessage.submissionTime.


3) Path: RecordDocketingMessage/ReviewFilingMessageReceiptTime



3) Path: RecordDocketingMessage/ReviewedDocument



105

106

4.4 RecordDocketingCallbackMessageTypeThe structure of a Record Docketing Callback Message will be documented in this section. This describes the Record Docketing Callback transaction between the Filing Review MDE and the Court Record MDE. This information will communicate the outcome of the Record Docketing Message between the Court Record MDE and the Filing Review MDE but does not necessarily describe the information that is actually stored in the Court Record.

The synchronous response will indicate the action taken by the court during the recording process on the documents transmitted with the review filing message.


4.4.1.1 Record Docketing Call Back Domain Model



931932933934935

936937

938

939

940

107

108

4.4.1.2 Record Docketing Callback Data DictionaryClass Property or Reference Definition and Notes

CallbackMessage 1) Definition needed.




3) Path: Submission/SubmissionReceivedDate




3) Path: Submission/SubmissionReceivedTime

MessageReceiptMessage 1) A message returned synchronously to indicate receipt by an MDE of another message. The name "MessageReceipt" suggested by S. Durham June 30 2005, and adopted by consensus on a TC call that day. The intent is that this will serve as the synchronous reply to all MDE operations that have an additional, asynchronous callback.

2) Path: MessageReceiptMessageType

originalMessageID 1) The identifier, assigned by the messaging profile in effect, to the original message sent to the MDE that prompted the return of this receipt.


3) Path: MessageReceiptMessage/OriginalMessageID/ID

4) Additional Notes: OriginalMessageID of IDType

originalMessageReceiptDate 1) Date on which the original message was received at the MDE, on the MDE's clock.


3) Path: MessageReceiptMessage/OriginalMessageReceiptDate


originalMessageReceiptTime 1) Time at which the original message was received at the MDE, on the MDE's clock.


3) Path: MessageReceiptMessage/OriginalMessageReceiptTime

Error 1) Representation of an error that occurred when synchronously processing the message.

2) OPTIONAL ELEMENT. Minimum occurrence is zero and Maximum occurrence is many. (0,*) This will control sub elements.

3) Path: ErrorType

errorCode 1) A code that uniquely identifies an error. Allowable values set forth in court policy.


3) Path: Error/ErrorCode




941

942

109

110


errorDescription 1) A more "user friendly" description of the error.


3) Path: Error/ErrorDescriptionText


ElectronicFilingCallbackMessage 1) Definition needed.

2) Path: ElectronicFilingCallbackMessageType


filingStatusCode 1) Status of the filing as determined by the system sending the callback. Values: accepted, partially accepted (e.g., some documents but not others), rejected.


3) Path: ElectronicFilingCallbackMessage/FilingStatusCode


filingStatusReasonDescription 1) A textual description of the reason for the setting of the status in the filingStatusCode.


3) Path: ElectronicFilingCallbackMessage/FilingStatusReasonDescription




3) Path: ElectronicFilingCallbackMessage/ReviewedDocument

4) Additional Notes: of ReviewedDocumentType

DocketedCase 1) This association will always be present, except in the situation where the filing was a case initiation filing and was rejected (therefore, no case was initiated in the court record system.)


3) Path: ElectronicFilingCallbackMessage/DocketedCase

4) Additional Notes: of CaseType

DocketedCase 1) A case that has been initiated in the court record system.

2) Path: CaseType









111

112


























113

114

4.5 CourtPolicyMessageTypeThe structure of a Court Policy Message will be documented in this section. This describes the Court Policy transaction between the Any MDE and the Court Policy MDE. This information will communicate the development time and run time policies that are implemented within the specified court.

The asynchronous response will indicate the expressed policies regarding the court’s electronic filing process.


4.5.1.1 Court Policy Message Domain Model

4.5.1.2 Court Policy Data DictionaryClass Property or Reference Definition and Notes

AllowedCodeValue 1) A value allowed for the parent identified element, and associated information.

2) Path: AllowedCodeValueType

value 1) The value that is transmitted in the message.


3) Path: AllowedCodeValue/ValueText


displayText 1) A description to be used for display purposes.


3) Path: AllowedCodeValue/DisplayText




943944945946

947

948

949

950

951

115

116


effectiveDate 1) The date on which this value became or will become allowed.


3) Path: AllowedCodeValue/EffectiveDate


expirationDate 1) The date on which the value was or will be terminated.


3) Path: AllowedCodeValue/ExpirationDate


CoreCodelist 1) Definition needed.

2) Path: CoreCodelistType

elementName 1) Definition needed.


3) Path: CoreCodelist/ElementName


AllowedCodeValue 1) Definition needed.


3) Path: CoreCodelist/AllowedCodeValue


CourtExtension 1) A structure representing the court-specific extensions for the court associated with this Court Policy.

2) Path: CourtExtensionType

ExtensionReference 1) Definition needed.


3) Path: CourtExtension/ExtensionReference

CourtPolicyMessage 1) Definition needed.

2) Path: CourtPolicyMessageType




117

118


policyVersionIdentifier 1) The version of court policy reported by this message. Up to the court to define the format of this, and describe in human-readable court policy.


3) Path: CourtPolicyMessage/PolicyVersionID

4) Additional Notes: of IDType

lastUpdateDate 1) Definition needed.


3) Path: CourtPolicyMessage/PolicyLastUpdateDate


RuntimePolicyParameters 1) Definition needed.


3) Path: CourtPolicyMessage/RuntimePolicyParameters

DevelopmentPolicyParameters 1) Definition needed.


3) Path: CourtPolicyMessage/DevelopmentPolicyParameters

DevelopmentPolicyParameters 1) Definition needed.

2) Path: DevelopmentPolicyParametersType

urlAttachmentSupported 1) Whether court allows attachments via remote URLs.


3) Path: DevelopmentPolicyParameters/URLAttachmentSupportedIndicator

4) Additional Notes: of type j-xsd:boolean

acceptDocumentsRequiringFees 1) Definition needed.


3) Path: DevelopmentPolicyParameters/AcceptDocumentsRequiringFeesIndicator




119

120


acceptConfidentialFilings 1) Definition needed.


3) Path: DevelopmentPolicyParameters/AcceptConfidentialFilingsIndicator


acceptMultipleLeadDocuments 1) Does court accept placing multiple lead documents in a single message


3) Path: DevelopmentPolicyParameters/AcceptMultipleLeadDocumentsIndicator


maximumAllowedAttachmentSize 1) The maximum allowed attachment size, in bytes. Does not appear if there is no maximum.


3) Path: DevelopmentPolicyParameters/MaximumAllowedAttachmentSize

4) Additional Notes: of type MeasureType, use measureUnitText attribute to report units

maximumAllowedMessageSize 1) Maximum allowed size of the Court Filing Message Stream, in bytes. Does not appear if there is no maximum.


3) Path: DevelopmentPolicyParameters/MaximumAllowedMessageSize

4) Additional Notes: of type MeasureType, use measureUnitText attribute to report units

supportedCallbackModelIdentifier 1) A URI (allowed values defined in the specification) identifying whether this court sends case information back to the Filing Assembly MDE in the Filing Review Callback message, or whether it supports the GetCaseQuery. To be compliant with the specification, a court must do one or the other.


3) Path: DevelopmentPolicyParameters/SupportedCallbackModelIdentifier

4) Additional Notes: of type IDType

SupportedProfile 1) Definition needed.


3) Path: DevelopmentPolicyParameters/SupportedProfile

CourtExtension 1) Definition needed.


3) Path: DevelopmentPolicyParameters/CourtExtension



121

122


ExtensionReference 1) A structure representing a court-specific data structure passed to a particular operation on a particular MDE.

2) Path: ExtensionReferenceType

mdeName 1) Definition needed.


3) Path: ExtensionReference/MajorDesignElementName


operationName 1) Definition needed.


3) Path: ExtensionReference/OperationName


argumentSchema 1) An XML Schema document that defines the allowable structure of the court-specific argument to this MDE operation.


3) Path: ExtensionReference/ArgumentSchema

4) Additional Notes: xsd:any

PublicKeyInformation 1) Need to get this from an existing standard.

QName 1) Definition needed.

2) Path: xsd:Qname

RuntimePolicyParameters 1) Definition needed.

2) Path: RuntimePolicyParametersType

PublicKeyInformation 1) Definition needed.


3) Path: RuntimePolicyParameters/PublicKeyInformation

CoreCodelist 1) Definition needed.


3) Path: RuntimePolicyParameters/CoreCodelist


SupportedProfile 1) Definition needed.

2) Path: SupportedProfileType

profileIdentifier 1) An identifier, from a list of allowed values defined in the Court Filing specification, of a profile supported by this court.


3) Path: SupportedProfile/profileIdentifier

4) Additional Notes: of IDType

XMLSchema 1) Definition needed.

2) Path: xsd:any



952

953

123

124

4.6 ServiceInformationQueryMessageTypeThe structure of a Service Information Query Message will be documented in this section. This describes the Service Information Query transaction between the Filing Assembly MDE and the Service Registry MDE. This information will communicate the parties service information for a specified but does not necessarily describe the information about the actual service being performed.

The synchronous request and response will indicate the service information for all parties and will be transmitted within the message.


4.6.1.1 Domain Model

Note: Person, Organization, ServiceRecipient, and ContactInformation mapped on ReviewFiling

4.6.1.2 Service Information Query Data DictionaryClass Property or Reference Definition and Notes

ElectronicFilingQueryMessage 1) Definition needed.

2) Path: ElectronicFilingMessageType


queryID 1) A unique identifier for the query assigned by the Filing Assembly MDE.


3) Path: ElectronicFilingMessage/ActivityID/ID



954955956957

958

959

960

961

962963

964

125

126


inquirerID 1) A unique identifier for a person or organization which submits a query.


3) Path: ElectronicFilingQueryMessage/SubmissionSubmitterID/ID



3) Path: ElectronicFilingQueryMessage/ActivityCourt/OrganizationID/ID

inquirerMDELocationID 1) The location of the filing assembly MDE associated with the person making the query.


3) Path: ElectronicFilingQueryMessage/InquirerMDELocationID/ID

ServiceInformationQueryMessage 1) Definition needed.

2) Path: ServiceInformationQueryMessageType




3) Path: ServiceInformationQueryMessage/Case/CaseTrackingID/ID

4.6.1.3 Service Information Response Data DictionaryClass Property or Reference Definition and Notes

ElectronicFilingResponseMessage 1) Definition needed.

2) Path: ElectronicFilingResponseMessageType


queryID 1) A unique identifier for the query assigned by the Filing Assembly MDE.


3) Path: ElectronicFilingResponseMessage/ActivityID/ID

inquirerID 1) A unique identifier for a person or organization which submits a query.


3) Path: ElectronicFilingResponseMessage/SubmissionSubmitterID/ID



3) Path: ElectronicFilingResponseMessage/ActivityCourt/OrganizationID/ID



965

966

967

127

128


queryError 1) A query error should be generated when: * The query arguments are considered to be invalid by the receiver, and the query cannot be processed. * The query represents a request for a specific data item, which cannot be retrieved. (another flavor of 'invalid argument') * The receiving system explicitly fails while processing the query.


3) Path: ElectronicFilingResponseMessage/QueryErrorText

ServiceInformationResponseMessage 1) Definition needed.

2) Path: ServiceInformationResponseMessageType




3) Path: ServiceInformationResponseMessage/ServiceRecipient.Person



3) Path: ServiceInformationResponseMessage/ServiceRecipient.Organization



968

969

129

130

4.7 CalculatedFeesQueryMessageTypeThe structure of a Calculated Fees Query Message will be documented in this section. This describes the Calculated Fees Query transaction between the Filing Assembly MDE and the Filing Review MDE. This information will communicate the fees to be charged for the specified filing.

The synchronous request and response will indicate the fee information for expected filing transmission within the message.



Note: ElectronicFilingQueryMessage and ElectronicFilingResponseMessage mapped in GetServiceInformationQuery

Note: ReviewFilingMessage mapped in ReviewFiling



970971972973

974

975

976

977978

979

131

132

4.7.1.2 Calculated Fees Query Data DictionaryClass Property or Reference Definition and Notes

CalculatedFeesQueryMessage 1) This query is a request for court fees of one or more documents in a case.

2) Path: CalculatedFeesQueryMessageType


ReviewFilingMessage 1) Definition needed.


3) Path: CalculatedFeesQueryMessage/ReviewFilingMessage

4.7.1.3 Calculated Fees Response Data DictionaryClass Property or Reference Definition and Notes

CalculatedFeesResponseMessage 1) Definition needed.

2) Path: CalculatedFeesResponseMessageType


filingFee 1) A fee or price required to submit a document.


3) Path: CalculatedFeesResponseMessage/CalculatedFeeAmount

4) Additional Notes: AmountType



980

981

982

983

984

133

134

4.8 CaseQueryMessageTypeThe structure of a Case Query Message will be documented in this section. This describes the Case Query transaction between the Filing Assembly MDE and the Query MDE. This Case query information will communicate all information about the case that is stored in the courts record.

The synchronous request and response will indicate the case information needed in the query message.




Note: Leaving this mostly undone, since we need to re-model GetCaseQuery, this will significantly change the mapping

4.8.1.2 Case Query Data DictionaryClass Property or Reference Definition and Notes

CaseQueryMessage 1) Definition needed.

2) Path: CaseQueryMessageType


CaseParticipant 1) Definition needed.


3) Path: CaseQueryMessage/CaseParticipant

CaseDocument 1) Definition needed.


3) Path: CaseQueryMessage/CaseDocument



985986987988

989

990

991

992993

994

995

135

136


CaseEventQueryInfo 1) Definition needed.


3) Path: CaseQueryMessage/CaseEvent


2) Path: CaseQueryMessageType

personName 1) Definition needed.


3) Path: CaseQueryMessage/CaseParticipantName



3) Path: CaseQueryMessage/FilingSubmitterID

TimeRange 1) A period of time bounded by upper and lower (to and from) dates/times.

2) Path: TimeRangeType

fromDate 1) Definition needed.


3) Path: TimeRange/FromDate


toDate 1) Definition needed.


3) Path: TimeRange/ToDate


fromTime 1) Definition needed.


3) Path: TimeRange/FromTime

toTime 1) Definition needed.


3) Path: TimeRange/ToTime



137

138


CaseDocument 1) Definition needed.

2) Path: DocumentDescriptiveMetadataType





CaseEventQueryInfo 1) Definition needed.

2) Path: CaseEventQueryInformationType

TimeRange 1) Definition needed.


3) Path: CaseEventQueryInformation/CaseEventTimeRange

4.8.1.3 Case Response Data Dictionary


CaseResponseMessage 1) Definition needed.

2) Path: CaseResponseMessageType

CaseInformation 1) Definition needed.


3) Path: CaseResponseMessage/Case

CaseTypeSpecificInformation 1) A representation of information structures that is specific to particular case types. When mapping to schema, the intent is that this would be implemented with a "choice" compositor.

CaseInformation 1) A temporary placeholder for the information about a case that is returned in a Get Case Query, as well as in the Review Filing callback.

CaseTypeSpecificInformation 1) Definition needed.


XMLDocument (CourtSpecificInformation) 1) Definition needed.


XMLDocument 1) A representation of an XML Document, with no particular structure, other than well-formed.



996

997

998

139

140

4.9 CaseListQueryMessageTypeThe structure of a Case List Query Message will be documented in this section. This describes the Case List Query transaction between the Filing Assembly MDE and the Query MDE. This Case List query response will communicate all information about the case that is stored in the courts record.

The synchronous request and response; the request will indicate which case is being queried and the related information will be supplied back in the response.



Note: TimeRange and CaseParticipant mapped in GetCaseQuery




999100010011002

10031004

1005

1006

10071008

1009

141

142

4.9.1.2 Case List Query Data DictionaryClass Property or Reference Definition and Notes

CaseListQueryMessage 1) This is a query for a list of cases that match a set of criteria including case participants, case classification, case status, and date of the case was initiated.

2) Path: CaseListQueryMessageType


caseStatus 1) A status of the case.


3) Path: CaseListQueryMessage/Case/CaseStatus/CaseStatusDescriptionText

4) Additional Notes: Case is of CaseType



3) Path: CaseListQueryMessage/Case/CaseClassification/CaseCategoryText




3) Path: CaseListQueryMessage/Case/CaseClassification/CaseSubCategoryText


caseTypeCode 1) NCSC term--get definition.


3) Path: CaseListQueryMessage/Case/CaseClassification/CaseTypeCode




3) Path: CaseListQueryMessage/CaseListQueryTimeRange



3) Path: CaseListQueryMessage/CaseListQueryCaseParticipant



1010

143

144

4.9.1.3 Case List Response Data DictionaryClass Property or Reference Definition and Notes

CaseListResponseMessage 1) Definition needed.

2) Path: CaseListResponseMessageType

MatchingCase 1) Definition needed.


3) Path: CaseListResponseMessage/MatchingCase

MatchingCase 1) Definition needed.

2) Path: MatchingCaseType

3) Additional Notes: extends CaseType



3) Path: MatchingCase/CaseClassification/CaseCategoryText




3) Path: MatchingCase/CaseTrackingID/ID

shortCaseTitle 1) An official name of a Case. No title exists when the message is initiating a new case.


3) Path: MatchingCase/CaseTitleText



3) Path: MatchingCase/CaseClassification/CaseSubCategoryText


caseStatus 1) A status of the case.


3) Path: MatchingCase/CaseStatus/CaseStatusDescriptionText

personName 1) Definition needed.


3) Path: MatchingCase/CaseParticipantName

personRelationshipToCaseTypeCode 1) Definition needed.


3) Path: MatchingCase/CaseParticipantRelationshipToCaseCode




1011

1012

145

146

4.10DocumentQueryMessageType The structure of a Document Query Message will be documented in this section. This describes the Document Query transaction between the Filing Assembly MDE and the Query MDE. This Document query response will communicate all information about the requested document that is stored in the courts record.

The synchronous request and response; the request will indicate which case document is being queried and the related document information will be supplied back in the response.



Note: Document structure (and associations) mapped in FilingReview




1013101410151016

10171018

1019

1020

1021

10221023

1024

147

148

4.10.1.2 Document Query Data DictionaryClass Property or

ReferenceDefinition and Notes

DocumentQueryMessage 1) Definition needed.

2) Path: DocumentQueryMessageType




3) Path: DocumentQueryMessage/Case/CaseTrackingID/ID



3) Path: DocumentQueryMessage/DocumentID/ID

4.10.1.3 Document Response Data DictionaryClass Property or


DocumentResponseMessage 1) Definition needed.

2) Path: DocumentResponseMessageType




3) Path: DocumentResponseMessage/Case/CaseTrackingID/ID



3) Path: DocumentResponseMessage/SubmissionSubmitterID/ID

Document 1) Definition needed.


3) Path: DocumentResponseMessage/Document



1025

1026

1027

1028

1029

1030

149

150

4.11 FilingQueryMessageTypeThe structure of a Filing Query Message will be documented in this section. This describes the Filing Query transaction between the Filing Assembly MDE and the Query MDE. This Filing query response will communicate all information about the requested filing that is stored in the courts record.

The synchronous request and response; the request will indicate which case filing is being queried and the related filing information will be supplied back in the response.


4.11.1.1Domain Model

4.11.1.2Filing Query Data DictionaryClass Property or


FilingQueryMessage 1) This query message is a request for a filing identified by filingID.

2) Path: FilingQueryMessageType




3) Path: FilingQueryMessage/ActivityID/ID



1031103210331034

10351036

1037

1038

1039

1040

1041

151

152

4.11.1.3Filing Response Data Dictionary

Class Property or Reference

Definition and Notes

FilingResponseMessage 1) Definition needed.

2) Path: FilingResponseMessageType




3) Path: FilingResponseMessage/ActivityID/ID



3) Path: FilingResponseMessage/Case/CaseTrackingID/ID


2) Path: FilingResponseMessage/SubmissionReceivedDate



2) Path: FilingResponseMessage/SubmissionReceivedTime



3) Path: FilingResponseMessage/SubmissionSubmitterID/ID

FilingDocuments 1) Definition needed.


3) Path: FilingResponseMessage/FilingDocuments



1042

1043

153

154



FilingDocuments 1) Definition needed.

2) Path: FilingDocumentsType

3) Additional Notes: extends DocumentDescriptiveMetadataType



3) Path: DocumentDescriptiveMetadata/DocumentID/ID





documentDescription 1) Name of document given by filer. Intended to supplement what is contained in the document type identifier property.


3) Path: DocumentDescriptiveMetadata/DocumentDescriptionText



1044

155

156

4.12FilingListQueryMessageTypeThe structure of a Filing List Query Message will be documented in this section. This describes the Filing Query transaction between the Filing Assembly MDE and the Query MDE. This Filing List query response will communicate a listing of all filing information about the requested case that is stored in the courts record.

The synchronous request and response; the request will indicate which case’s filings are being queried and the related list of filing information will be supplied back in the response.



Note: TimeRange mapped in GetCaseQuery




1045104610471048

10491050

1051

1052

10531054

1055

157

158

4.12.1.2 Filing List Query Data DictionaryClass Property or Reference Definition and Notes

FilingListQueryMessage 1) This is query to get a list of filings by Filer Identification, Case Identifier, or time period.

2) Path: FilingListQueryMessageType




3) Path: FilingListQueryMessage/Case/CaseTrackingID/ID

filerID 1) A unique identifier for a person or organization which requests information.


3) Path: FilingListQueryMessage/SubmissionSubmitterID/ID



3) Path: FilingListQueryMessage/QueryTimeRange

4.12.1.3 Filing List Response Data DictionaryClass Property or Reference Definition and Notes

FilingListResponseMessage 1) Definition needed.

2) Path: FilingListResponseMessageType

MatchingFiling 1) Definition needed.


3) Path: FilingListResponseMessage/MatchingFiling

MatchingFiling 1) Definition needed.

2) Path: MatchingFilingType




3) Path: MatchingFiling/Case/CaseTrackingID/ID



1056

1057

1058

1059

159

160


caseTitle 1) An official name of a Case. No title exists when the message is initiating a new case.


3) Path: MatchingFiling/Case/CaseTitleText

caseShortTitle 1) An official name of a Case. No title exists when the message is initiating a new case.


3) Path: MatchingFiling/Case/CaseTitleText



3) Path: MatchingFiling/ActivityID/ID



3) Path: MatchingFiling/SubmissionSubmitterID/ID

filingStatus 1) Details about a status of an activity or process.


3) Path: MatchingFiling/ActivityStatus/StatusDescriptionText



3) Path: MatchingFiling/SubmissionReceivedTime



3) Path: MatchingFiling/SubmissionReceivedDate




1060

161

162

4.13FilingStatusQueryMessageTypeThe structure of a Filing Status Query Message will be documented in this section. This describes the Filing Status Query transaction between the Filing Assembly MDE and the Query MDE. This Filing Status query response will communicate the filing status information about the requested case’s filing.

The synchronous request and response; the request will indicate which case’s filing are being queried and the related filing status information will be supplied back in the response.




4.13.1.2 Filing Status Query Data DictionaryClass Property or


FilingStatusQueryMessage 1) This is query to get a filing’s status by Filer Identification, Case Identifier, or Filing Number.

2) Path: FilingStatusQueryMessageType




3) Path: FilingStatusQueryMessage/ActivityID/ID



1061106210631064

10651066

1067

1068

106910701071

1072

1073

163

164



filerID 1) A unique identifier for a person or organization which requests information.


3) Path: FilingStatusQueryMessage/SubmissionSubmitterID/ID



3) Path: FilingStatusQueryMessage/Case/CaseTrackingID/ID

4.13.1.3 Filing Status Response Data DictionaryClass Property or


FilingStatusResponseMessage 1) Definition needed.

2) Path: FilingStatusResponseMessageType




3) Path: FilingStatusResponseMessage/ActivityID/ID



3) Path: FilingStatusResponseMessage/Case/CaseTrackingID/ID


2) Path: FilingStatusResponseMessage/SubmissionReceivedDate



2) Path: FilingStatusResponseMessage/SubmissionReceivedTime



3) Path: FilingStatusResponseMessage/SubmissionSubmitterID/ID

filingStatus 1) Details about a status of an activity or process.

2) MANDATORY ELEMENT. Minimum occurrence is once and Maximum occurrence is twice. (1,2)

3) Path: FilingStatusResponseMessage/ActivityStatus/StatusDescriptionText



1074

1075

1076

165

166

4.14FilingPaymentThe structure of a Filing Payment Message will be documented in this section. This describes the Filing Payment transaction between the Filing Assembly MDE and the Filing Review MDE. This Filing Payment query response will communicate the payment has been received for the case’s filing.

The synchronous request and response; the request will indicate the a filing payment is being made for a specific case filing and the related filing payment status information will be supplied back in the response.



4.14.1.2 Filing Payment Data DictionaryClass Property or Reference Definition and Notes

AllowanceCharge 1) An authorization by the filer allowing the court to take money from the filer, for a particular purpose, and by a particular means. Only for case-related activities. This may only be included with the ReviewFiling message sent to the court - it must not be included with the ReviewFiling message served to other parties in the case.

2) Path: cac:AllowanceCharge

paymentAmount 1) An amount of money that the filer is paying to the court.


3) Path: cac:AllowanceCharge/Amount

paymentPurposeCode 1) Purpose or reason for the filer's making the payment; this would be a code valid according to and described by Court Policy.


3) Path: cac:AllowanceCharge/ReasonCode




1077107810791080

10811082

1083

1084

1085

1086

1087

167

168


PaymentMeans 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans

1) Sub Element


3) Path: cac:AllowanceCharge/CurrencyCode

1) Sub Element


3) Path: cac:AllowanceCharge/PrepaidIndicator

1) Sub Element


3) Path: cac:AllowanceCharge/ID

1) Sub Element


3) Path: cac:AllowanceCharge/ChargeIndicator

1) Sub Element


3) Path: cac:AllowanceCharge/MultiplierFactorNumeric

1) Sub Element


3) Path: cac:AllowanceCharge/SequenceNumeric



169

170


Branch 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch/ID

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch/Name

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch/FinancialInstitution

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch/Address

FinancialAccount 1) Definition needed.

2) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount

bankRoutingNumber 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch/FinancialInstitution/ID

bankAccountNumber 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/ID

accountOwnerName 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Name

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/AccountTypeCode



171

172


1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/CurrencyCode

FinancialInstitution 1) Definition needed.

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch/FinancialInstitution/ID

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch/FinancialInstitution/Name

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/PayerFinancialAccount/Branch/FinancialInstitution/Address

CreditAccount 1) Definition needed.

2) Path: cac:AllowanceCharge/PaymentMeans/CreditAccount

accountNumber 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/CreditAccount/AccountID

PaymentMeans 1) Definition needed.

2) Path: cac:AllowanceCharge/PaymentMeans

paymentMeansCode 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/PaymentMeansCode


Payment 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/Payment/PaidAmount

CreditAccount 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/CreditAccount

CardAccount 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount



173

174


FinancialAccount 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/FinancialAccount

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMean/DuePaymentDate

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMean/PaymentChannelCode

FilingPayment 1) Definition needed.

2) Path: FilingPayment

feeExceptionReasonCode 1) Sub Element


3) Path: FilingPayment/FeeExceptionReasonCode

feeExceptionSupportingText 1) Sub Element


3) Path: FilingPayment/FeeExceptionSupportingText

payerName 1) Definition needed.


3) Path: FilingPayment/PayerName

AllowanceCharge 1) Definition needed.


3) Path: cac:AllowanceCharge

accountOwnerAddress 1) Definition needed.

2) Path: cac:Address

Payment 1) Definition needed.

2) Path: cac:Payment

transactionIdentifier 1) An identifier that uniquely identifies the vendor, mechanism, etc., that handled this payment.


3) Path: cac:Payment/ID

4) Additional Notes: From UBL

transactionDate 1) Definition needed.


3) Path: cac:Payment/ReceivedDate


transactionTime 1) Definition needed.




175

176


1) Sub Element


3) Path: cac:Payment/PaidAmount

CardAccount 1) Definition needed.

2) Path: cac:AllowanceCharge/PaymentMeans/CardAccount

accountNumber 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/PrimaryAccountNumberID

accountOwnerName 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/HolderName

cardTypeCode 1) Allowable types listed in court policy.


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/CardTypeCode


cardExpirationDate 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/ExpiryDate


cardSecurityNumber 1) Definition needed.


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/CV2ID

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/NetworkID

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/CustomerID

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/IssuerID

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/IssueNumberID



177

178


1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/ChipCode

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/ChipApplicationID

1) Sub Element


3) Path: cac:AllowanceCharge/PaymentMeans/CardAccount/ValidityStartDate

AmountType 1) Definition needed.

2) Path: cbc:PaymentAmount



1088

179

180

4.15CaseTypeSpecificInformationType

4.15.1 BankruptcyThe structure of a Bankruptcy Case Type Specific Information will be included in other messages will be documented in this section. This describes the unique Bankruptcy case elements that are needed to initiate a case in the court records for a filing. This information is supporting primary transactions between the Filing Assembly MDE and the Filing Review MDE.

The party requesting an equitable distribution of property is referred to as the initiating party. The responding party will be party being affected by the equitable distribution of property.


4.15.1.1 Bankruptcy Domain Model

4.15.1.2 Bankruptcy Data Dictionary

Class Property or Reference Definition

BankruptcyCaseInformation 1) Additional information specific to bankruptcy cases.

2) Path: BankruptcyCaseInformationType

assetNotice 1) Whether assets are available for distribution to creditors.


3) Path: BankruptcyCaseInformation/AssetNoticeIndicator

numberOfCreditorsvalueLevelCode 1) A coded set of ranges of numbers of creditors involved in the case.


3) Path: BankruptcyCaseInformation/NumberOfCreditorsValueLevelCode


document.doc 9 September 2005

Copyright © OASIS Open 2005. All Rights Reserved. of 137

1089

1090109110921093

10941095

1096

1097

1098

1099

1100

1101

181

182

183

184


estimatedAssetsValueLevelCode 1) A coded set of ranges of dollar values for assets. Generally used for statistical reporting, not case management.


3) Path: BankruptcyCaseInformation/EstimatedAssetsValueLevelCode


estimatedDebtsValueLevelCode 1) A coded set of ranges of dollar values for debts. Generally used for statistical reporting, not case management.


3) Path: BankruptcyCaseInformation/EstimatedDebtsValueLevelCode


smallBusiness 1) Whether the initiating party is a small business, as defined in bankruptcy code.


3) Path: BankruptcyCaseInformation/SmallBusinessIndicator

section1121e 1) The debtor has elected to proceed under Section 1121 (e) of the bankruptcy code.


3) Path: BankruptcyCaseInformation/Section1121eIndicator

debtorTypeCode 1) "Form of Origin" indicator...one of seven code values from the Bankruptcy Petition Form.


3) Path: BankruptcyCaseInformation/DebtorTypeCode


jointPetitionIndicator 1) Whether or not spouses are filing as joint debtors


3) Path: BankruptcyCaseInformation/JointPetitionIndicator

natureOfDebtCode 1) Whether the debts involved in the case are "business" or "consumer".


3) Path: BankruptcyCaseInformation/NatureOfDebtCode




185

186

187

188


voluntaryIndicator 1) Whether the debtor has initiated bankruptcy (true, corresponding to Federal code "V") or a creditor has initiated bankruptcy (false, corresponding to Federal code "I")


3) Path: BankruptcyCaseInformation/VoluntaryIndicator

BankruptcyStatute 1) Definition needed.


3) Path: BankruptcyCaseInformation/BankruptcyStatute

Debtor 1) Definition needed.


3) Path: BankruptcyCaseInformation/Debtor.Person, BankruptcyCaseInformation/Debtor.Organization

BankruptcyStatute 1) Definition needed.

2) Path: StatuteType

chapterIdentifierCode 1) The chapter of the bankruptcy code under which the debtor has chosen to proceed.


3) Path: Statute/StatuteCodeSectionID/ID


Debtor 1) Definition needed.


3) Path: Mapped to Person and Organization individually, with schema choice compositor

taxIdentifier 1) Definition needed.

PersonDebtor 1) Definition needed.

2) Path: PersonType

personPartyIDReference 1) The value of the Person.ID property in the ReviewFiling message, linking this debtor to the appropriate party.





189

190

191

192




3) Path: Person/PersonAssignedIDDetails/PersonTaxID/ID

OrganizationDebtor 1) Definition needed.


organizationPartyIDReference 1) The value of the Organization.ID property in the ReviewFiling message, linking this debtor to the appropriate party.


3) Path: Organization/OrganizationID/ID



3) Path: Organization/OrganizationTaxID/ID



1102

193

194

195

196

4.15.2 CivilThe structure of a Civil Case Type Specific Information will be included in other messages will be documented in this section. This describes the unique Civil case elements that are needed to initiate a case in the court records for a filing. This information is supporting primary transactions between the Filing Assembly MDE and the Filing Review MDE.

The following cases will be supported general civil, mental health, probate and small claims.

Guardianship/conservatorship – the person seeking to establish a guardianship or conservatorship is the initiating party; the person for whom the guardianship or conservatorship is to be established is the responding party; “otherActor” is used for other interested parties

A personal representative or executor is the initiating party in a probate case. OtherActor is used for interested parties. There is no responding party.

For an action creating a trust, the trustor is the initiating party, the trustee is the responding party and the beneficiary is an otherActor.

In an interpleader action, the person filing the suit is the initiating party. All potentially interested persons are treated as responding parties.


4.15.2.1 Civil Domain Model



1103110411051106

1107

11081109

11101111

1112

1113

1114

1115

1116

1117

197

198

199

200

4.15.2.2 Civil Data DictionaryClass Property or Reference Definition and Notes

CivilCaseInformation 1) Definition needed.

2) Path: CivilCaseType

reliefTypeCode 1) Indicator of the type of relief requested in the case, e.g., damages, equitable relief (injunction). Allowable values defined in Court Policy.


3) Path: CivilCase/ReliefTypeText


amountInControversy 1) The amount set forth in an ad damnum clause in a complaint, counter claim, or cross complaint.


3) Path: CivilCase/AmountInControversy

jurisdictionalGroundsCode 1) The grounds for invoking the jurisdiction of a limited jurisdiction court. Allowed values set forth in Court policy. Not used in general jurisdiction courts.


3) Path: CivilCase/JurisdictionalGroundsText


juryDemandIndicator 1) Whether filer invokes the right to trial by jury.


3) Path: CivilCase/JuryDemandIndicator

classActionIndicator 1) Whether the filer is requesting that this case proceed as a class action.


3) Path: CivilCase/ClassActionIndicator

causeOfActionCode 1) The legal ground on which the request for relief is based. This is the fourth level of case classification/type, for civil cases. Allowable values set forth in Court Policy.


3) Path: CivilCase/CauseOfActionText


initiatingPartyCitizenshipTypeCode 1) Used for Federal court purposes: a code designating the state or country of citizenship for purposes of applying Federal diversity of citizenship jurisdictional rules. Allowable values set forth in court policy.


3) Path: CivilCase/InitiatingPartyCitizenshipTypeText


respondingPartyCitizenshipTypeCode 1) Used for Federal court purposes: a code designating the state or country of citizenship for purposes of applying Federal diversity of citizenship jurisdictional rules. Allowable values set forth in court policy.


3) Path: CivilCase/RespondingPartyCitizenshipTypeText




1118

201

202

203

204


FiduciaryCaseInformation 1) Definition needed.


3) Path: CivilCase/FiduciaryCase

4) Additional Notes: implement with choice structure in schema

DecedentEstateCaseInformation 1) Definition needed.


3) Path: CivilCase/DecedentEstateCase

DecedentEstateCaseInformation 1) Information about a case administering and distributing the assets of a testate or intestate decedent.

2) Path: DecedentEstateCaseType

dateOfDeath 1) Definition needed.


3) Path: DecedentEstateCase/DecedentDeathDate


dateOfWillFiling 1) Definition needed.


3) Path: DecedentEstateCase/WillFilingDate


nameOfDeceased 1) Definition needed.


3) Path: DecedentEstateCase/DecedentFullName

FiduciaryCaseInformation 1) Information about a guardianship, conservatorship, trust, or mental health case.

2) Path: FiduciaryCaseType

fiduciaryTypeCode 1) Legal description of the role of the fiduciary. This is needed in addition to the Case Role Code (in the Review Filing message structure) because that code only defines the roles of other actors and other parties; the fiduciary per the specification is the initiating party. Examples: guardian, trustee, conservator of the person, conservator of the estate.


3) Path: FiduciaryCase/FiduciaryTypeCode




205

206

207

208


PersonInformation 1) Definition needed.


3) Path: FiduciaryCase/Person

PersonInformation 1) Information about the person for whom another person or organization is assuming a fiduciary obligation.

2) Path: FiduciaryCasePersonType

3) Additional Notes: extends GJXDM PersonType

dateOfBirth 1) The year, month, and day on which a person was born.


3) Path: FiduciaryCasePerson/PersonBirthDate


height 1) The numeric representation (including unit of measure) of the measurement from head to foot of the person.


3) Path: FiduciaryCasePerson/PersonPhysicalDetails/PersonHeightMeasure

4) Additional Notes: inherited from PersonType; include units attribute

weight 1) The numeric representation (including unit of measure) of the weight of the person.


3) Path: FiduciaryCasePerson/PersonPhysicalDetails/PersonWeightMeasure

4) Additional Notes: inherited from PersonType

raceCode 1) A designation by the FBI categorizing individuals by physical characteristics. (e.g., American Indian or Alaskan native, Asian or Pacific Islander, Black, White, Unknown).


3) Path: FiduciaryCasePerson/PersonPhysicalDetails/PersonRaceText


sexCode 1) One of the two divisions, male and female, into which many living things are grouped. (Ex. M-Male, F-Female, U-Unknown).


3) Path: FiduciaryCasePerson/PersonPhysicalDetails/PersonSexText




209

210

211

212


relationshipToFiduciary 1) Description of this person's relationship to the fiduciary (i.e., the initiating party).


3) Path: FiduciaryCasePerson/PersonFiduciaryRelationshipText

personIdentifier 1) Definition needed.


3) Path: FiduciaryCasePerson/PersonAssignedIDDetails/PersonOtherID/ID

4) Additional Notes: inherited from PersonType

ethnicityCode 1) A NIBRS code representing the nation or cultural group to which a referenced subject belongs.


3) Path: FiduciaryCasePerson/PersonSocialDetails/PersonEthnicityText


CurrencyAmount 1) Definition needed.

2) Path: AmountType

WeightMeasureType 1) Definition needed.

2) Path: WeightMeasureType

HeightMeasureType 1) Definition needed.

2) Path: HeightMeasureType



1119

213

214

215

216

4.15.3 CriminalThe structure of a Criminal Case Type Specific Information will be included in other messages will be documented in this section. This describes the unique Criminal case elements that are needed to initiate a case in the court records for a filing. This information is supporting primary transactions between the Filing Assembly MDE and the Filing Review MDE. In addition person specific information has been extended using the ExtendedPersonInformation to represent the needs of the criminal justice community regarding a subject identity.

The following cases will be felony and misdemeanor criminal cases.

The prosecutor is the initiating party; the suspect/defendant(s) is the responding party.


4.15.3.1 Criminal Domain Model



11201121112211231124

1125

1126

1127

1128

1129

217

218

219

220

4.15.3.2 Criminal Data DictionaryClass Property or Reference Definition and Notes

CriminalFiling 1) Definition needed.

2) Path: CriminalFilingType

3) Additional Notes: Extends CaseType

prosecutionRecommendedBail 1) The bail amount recommended by the prosecutor.


3) Path: CriminalFiling/ProsecutionRecommendedBailText

preliminaryHearingDurationEstimate 1) Definition needed.


3) Path: CriminalFiling/PreliminaryHearingDurationEstimateText

prosecutionCaseNumber 1) Case Number assigned by the Prosecuting Attorney.


3) Path: CriminalFiling/CaseParticipants/CaseProsecutionAttorney/CaseOfficialCaseID/ID

4) Additional Notes: from CaseType

Defendant 1) Definition needed.


3) Path: CriminalFiling/CaseParticipants/CaseDefendantParty.Person


Arrest 1) Definition needed.


3) Path: CriminalFiling/Arrest

Charge 1) Definition needed.


3) Path: CriminalFiling/CaseCharge


Charge (amended) 1) Definition needed.


3) Path: CriminalFiling/CaseAmendedCharge



2) Path: PersonType

defendantNumber 1) Sequential Number assigned to each Defendant.



4) Additional Notes: use IDTypeText='defendantNumber'



1130

221

222

223

224


federalBureauOfInvestigationNumber 1) Unique number assigned by the FBI to identify a subject. Ex. 617523A1, 14579A, etc.


3) Path: Person/PersonAssignedIDDetails/PersonFBIID/ID

stateIDNumber 1) Unique number assigned to persons by the Department of Public Safety (or similar state agency) based on fingerprint identification.


3) Path: Person/PersonAssignedIDDetails/PersonStateID/ID

localFingerprintBasedIDNumber 1) Unique number assigned to persons by a local (county or municipal) Automated Fingerprint Identification System based on fingerprint identification.


3) Path: Person/PersonAssignedIDDetails/PersonAFISID/ID

localAgencyIDNumber 1) An identifier that does not belong to one of the standard explicitly defined types such as FBI Number or Social Security Number.



localAgencyIDType 1) A name or brief descriptor of an identifier not belonging to one of the standard explicitly defined types such as FBI Number or State Identification Number.


3) Path: Person/PersonAssignedIDDetails/PersonOtherID/IDTypeText

4) Additional Notes: use IDTypeText w/ value other than those specified here

custodyStatusCode 1) Definition needed.


3) Path: Person/PersonInCustodyIndicator





4) Additional Notes: use IDTypeText='personIdentifier'

prisonerIdentifier 1) An identifier for the defendant as an inmate or prisoner.


3) Path: Person/PersonAssignedIDDetails/PersonOtherID

4) Additional Notes: use IDTypeText='prisonerIdentifier'

defendantArrestWarrantIssuedIndicator 1) Indicates whether an arrest warrant has been issued against the defendant.


3) Path: Person/PersonArrestWarrantIssuedIndicator

ExtendedPersonInformation 1) Definition needed.


3) Path: self (map to PersonType, see ExtendedPersonInformation tab)



225

226

227

228


Arrest 1) Definition needed.

2) Path: ArrestType

arrestDate 1) The year, month, and day that the subject was arrested.


3) Path: Arrest/ActivityDate


arrestTime 1) Time of an arrest.


3) Path: Arrest/ActivityTime

incidentNumber 1) Unique identifier for a police agency departmental report.


3) Path: Arrest/ArrestAgencyRecordID/ID

arrestingAgencyID 1) An alphanumeric identifier issued by the FBI to identify a specific criminal justice agency, in this instance the law enforcement agency which made the arrest. (Ex. AZ0071300, etc.)


3) Path: Arrest/ArrestAgency/OrganizationORIID/ID

arrestingAgencyName 1) The name of the Law Enforcement agency which made the arrest.


3) Path: Arrest/ArrestAgency/OrganizationName

arresteeBloodAlcoholContentNumber 1) The percentage of alcohol in an arrestee's blood (e.g. .08%).


3) Path: Arrest/ArrestBloodAlcoholContentNumberText

bookingNumber 1) Number issued by booking agency at time of subject's entry into jail and maintained until release on all charges and sentences. New number issued for each subsequent jail stay.


3) Path: Arrest/Booking/BookingAgencyRecordID/ID

bookingAgencyID 1) An alpha numeric identifier issued by the FBI to identify a specific criminal justice agency. In this instance the Law Enforcement Agency which booked the suspect into jail. (Ex. AZ0071300, etc.)


3) Path: Arrest/Booking/BookingAgency/OrganizationORIID/ID

bookingAgencyName 1) The name of the Law Enforcement Agency which booked the suspect into jail.


3) Path: Arrest/Booking/BookingAgency/OrganizationUnitName



229

230

231

232


defendantExtraditionStatus 1) A code identifying the type of limitation placed on the extradition of a subject from an area outside the immediate jurisdiction of the issuing court.


3) Path: Arrest/ArrestWarrant/WarrantExtraditionLimitationCode



3) Path: Arrest/ArrestSubjectReference



3) Path: Arrest/ArrestCharge


2) Path: ChargeType

countNumber 1) A numeric designator identifying the order of a specific charge. (Ex. Count 1 represented as 001, Count 2 as 002, Count 3 as 003, etc.).


3) Path: Charge/ChargeSequenceID/ID

chargeOffenseStartTime 1) The time of day that a violation of law is alleged to have occurred. Also, this attribute is to be used if only one offense time is recorded.


3) Path: Charge/ChargeOffense/ActivityTime

4) Additional Notes: ChargeOffense is of type IncidentType

chargeOffenseEndTime 1) The time at which the offense ended. Not used if only one offense time is recorded.


3) Path: Charge/ChargeOffense/ActivityEndTime


chargeOffenseLocationCounty 1) The name of the county where the offense was committed.


3) Path: Charge/ChargeOffense/IncidentLocation/LocationAddress/LocationCountyName


chargeOffenseLocationDescription 1) Brief description of the location where the offense occurred.


3) Path: Charge/ChargeOffense/IncidentLocation/LocationDescriptionText


chargeQualifier 1) A designation showing how the record offense has been enhanced. (Ex. Dangerousness, prior convictions, etc.) (Attempt, Conspiracy)


3) Path: Charge/ChargeClassification/ChargeApplicabilityText



233

234

235

236


chargeDegree 1) A designation indicating the degree of the charge when appropriate. (e.g. 2nd degree murder)


3) Path: Charge/ChargeClassification/ChargeDegreeText

chargeStatuteCodeSection 1) An identifier of a section or category within a code book.


3) Path: Charge/ChargeStatute/StatuteCodeSectionID/ID


chargeLevel 1) Defines the level of severity of a charged offense at the Time of . (Ex. Class 3 misdemeanor or Class 5 felony, etc.)


3) Path: Charge/ChargeStatute/StatuteLevelText

chargeDescription 1) Title or description of a specific charge.


3) Path: Charge/ChargeDescriptionText

chargeEnhancingAllegationCountNumber 1) A reference to the underlying Charge Count to which the Enhancing Allegation applies.


3) Path: Charge/ChargeClassification/ChargeEnhancingAllegationCharge/ChargeSequenceID/ID

chargeEnhancingAllegationStatuteCodeSection

1) Legal code Section Number referenced in the charge allegation.


3) Path: Charge/ChargeClassification/ChargeEnhancingAllegationCharge/ChargeStatute/StatuteCodeSectionID/ID


chargeEnhancingAllegationChargeDescriptionText

1) Title or description of the specific charge.


3) Path: Charge/ChargeClassification/ChargeEnhancingAllegationCharge/ChargeStatute/StatuteDescriptionText

chargeEnhancingAllegationTypeCode 1) Code describing the type of charge allegation.


3) Path: Charge/ChargeClassification/ChargeAllegationTypeCode


specialAllegation 1) Free form Text describing the details of the charge allegation.


3) Path: Charge/ChargeClassification/ChargeSpecialAllegationText



237

238

239

240


chargeOffenseStartDate 1) The date on which the offense started. Also, this attribute is used when only one offense date is recorded.


3) Path: Charge/ChargeOffense/ActivityDate


chargeOffenseEndDate 1) The date on which the offense ended. Not used if only one offense date is recorded.


3) Path: Charge/ChargeOffense/ActivityEndDate




3) Path: Charge/ChargeSubjectReference

4.15.3.3 Extended Person Information Domain Model



1131

1132

1133

1134

241

242

243

244

4.15.3.4 Extended Person Information Data DictionaryClass Property or Reference Definition and Notes

DriversLicense 1) Definition needed.

2) Path: DriverAuthorizationType

driversLicenseNumber 1) Definition needed.


3) Path: DriverAuthorization/DriverAuthorizationID/ID

driversLicenseJurisdictionCode 1) Definition needed.


3) Path: DriverAuthorization/DriverAuthorizationID/IDJurisdictionCode


driversLicenseCommercialClassCode 1) Definition needed.


3) Path: DriverAuthorization/DriverAuthorizationCommercialClassCode


driversLicenseExpirationDate 1) Definition needed.


3) Path: DriverAuthorization/DriverAuthorizationExpirationDate


driversLicenseSurrendered 1) Definition needed.


3) Path: DriverAuthorization/DriverAuthorizationSurrenderedIndicator

driversLicenseSurrenderedDate 1) Definition needed.


3) Path: DriverAuthorization/DriverAuthorizationSurrenderedDate


driversLicenseCountryCode 1) Definition needed.


3) Path: DriverAuthorization/DriverAuthorizationID/IDJurisdictionCode




1135

245

246

247

248


Fingerprint 1) A representation or an encoding of the identifying characteristics of a person's fingerprint.

2) Path: FingerprintType

fingerprintImageType 1) Name of the finger image that is being reported; example: right index, left ring, etc.


3) Path: Fingerprint/FingerprintFingerText

Image 1) Definition needed.


3) Path: Fingerprint/BiometricImage

FingerprintSet 1) A representation or an encoding of the identifying characteristics of a person's fingerprints.

2) Path: FingerprintSetType

classification 1) The full 10-print fingerprint classification by “Henry” or other method.


3) Path: FingerprintSet/BiometricValueText

classificationMethod 1) The classification technique employed in encoding the fingerprint set.


3) Path: FingerprintSet/BiometricEncodingMethodText

Fingerprint 1) Definition needed.

2) MANDATORY ELEMENT. Minimum occurrence is once and Maximum occurrence is ten times. (1,10)

3) Path: FingerprintSet/Fingerprint


2) Path: ImageType

imageData 1) A binary encoding of data, e.g., a binary encoding of a picture, photo, image, graphic, sound, or video.


3) Path: Image/BinaryObject.Base64

imageFormat 1) MIME Content type of the image format used (e.g., image/jpeg, image/gif, image/tiff). Use image/wsq for fingerprint images compressed using the ANSI/NIST/FBI recommended algorithm wavelet scalar quantization.


3) Path: Image/BinaryFormatText



249

250

251

252


imageSize 1) Size of the image, in bytes.


3) Path: Image/BinarySizeValue

imageType 1) Description of the type of image (mug shot, fingerprint, etc.) Also, for palm prints, encodes the information about which palm is being imaged (right, left, right writer's palm, left writer's palm, both palms, both writer's palms, unknown.)


3) Path: Image/BinaryTypeText

imageDescription 1) Additional free-text information about the image. This may be a note or comment about the image.


3) Path: Image/BinaryDescriptionText

imageHyperlink 1) A hyperlink to the image. The hyperlink may be a URL or URI or description of a file location.


3) Path: Image/BinaryReferenceID

captureDate 1) The date on which the DNA was captured.


3) Path: Image/BinaryCaptureDate


captureOrganizationName 1) The name of the organization that captured the DNA.


3) Path: Image/BinaryCaptureOrganization/OrganizationName

captureOrganizationID 1) The identifier (e.g., ORI) of the organization that captured the DNA.


3) Path: Image/BinaryCaptureOrganization/OrganizationID/ID


2) Path: PersonType

raceCode 1) A designation by the FBI categorizing individuals by physical characteristics. (e.g., American Indian or Alaskan native, Asian or Pacific Islander, Black, White, Unknown).


3) Path: Person/PersonPhysicalDetails/PersonRaceCode




253

254

255

256


raceText 1) A textual description categorizing individuals by physical characteristics. (e.g., American Indian or Alaskan native, Asian or Pacific Islander, Black, White, Unknown).


3) Path: Person/PersonPhysicalDetails/PersonRaceText

ethnicityCode 1) A NIBRS code representing the nation or cultural group to which a referenced subject belongs.


3) Path: Person/PersonSocialDetails/PersonEthnicityCode


ethnicityText 1) A textual description of the nation or cultural group to which a referenced subject belongs.


3) Path: Person/PersonSocialDetails/PersonEthnicityText

sexCode 1) One of the two divisions, male and female, into which many living things are grouped. (Ex. M-Male, F-Female, U-Unknown).


3) Path: Person/PersonPhysicalDetails/PersonSexCode


height 1) The numeric representation (including unit of measure) of the measurement from head to foot of the person.


3) Path: Person/PersonPhysicalDetails/PersonHeightMeasure

weight 1) The numeric representation (including unit of measure) of the weight of the person.


3) Path: Person/PersonPhysicalDetails/PersonWeightMeasure

dateOfBirth 1) The year, month, and day on which a person was born.


3) Path: Person/PersonBirthDate


hairColorCode 1) A code identifying the person's hair color at the time the information was collected.


3) Path: Person/PersonPhysicalDetails/PersonHairColorCode




257

258

259

260


eyeColorCode 1) A code identifying the person's eye color at the time the information was collected.


3) Path: Person/PersonPhysicalDetails/PersonEyeColorCode


socialSecurityNumber 1) Number issued by the federal government to all citizens, residents of the U.S. First three digits cannot be all zeroes. Numbers beginning with 9 indicate a non-resident alien. Ex. 123456789 or 356886777


3) Path: Person/PersonAssignedIDDetailsPersonTaxID/ID

ScarsMarksTattoos 1) Definition needed.


3) Path: Person/PersonPhysicalDetails/PersonPhysicalFeature

DriversLicense 1) Definition needed.


3) Path: Person/PersonDriverAuthorization

FingerprintSet 1) Definition needed.


3) Path: Person/PersonBiometricDetails/PersonFingerprintSet

PalmPrint 1) Definition needed.


3) Path: Person/PersonBiometricDetails/PersonPalmPrint

DNA 1) Definition needed.


3) Path: Person/PersonBiometricDetails/PersonDNA

ScarsMarksTattoos 1) A structure describing an identifying scar, mark, tattoo, amputation or other distinguishing physical feature.

2) Path: PhysicalFeatureType

scarsMarksTattoosCode 1) Definition needed.


3) Path: PhysicalFeature/PhysicalFeatureTypeCode


scarsMarksTattoosText 1) Definition needed.


3) Path: PhysicalFeature/PhysicalFeatureDescriptionText



261

262

263

264


DNA 1) A representation or an encoding of the identifying characteristics of a person's DNA.

2) Path: DNAType

encodingMethod 1) Method used to encode the DNA (only allowable value is "STR".)


3) Path: DNA/BiometricEncodingMethodText

additionalDescription 1) Additional free-text information or comment about the DNA


3) Path: DNA/BiometricDescriptionText

captureOrganizationName 1) The name of the organization that captured the DNA.


3) Path: DNA/BiometricCaptureOrganization/OrganizationName

captureOrganizationID 1) The identifier (e.g., ORI) of the organization that captured the DNA.


3) Path: DNA/BiometricCaptureOrganization/OrganizationID/ID

captureDate 1) The date on which the DNA was captured.


3) Path: DNA/BiometricCaptureDate


DNADetail 1) Definition needed.

2) MANDATORY ELEMENT. Minimum occurrence is once and Maximum occurrence is fourteen times. (1,14)

3) Path: DNA/DNALocus



265

266

267

268


DNADetail 1) Information about each locus in the STR (short tandem repeat) encoding.

2) Path: DNALocusType

dnaLocusType 1) The location within a strand of DNA that a value was determined. Allowable values: Amelogenin, D5S818, CSF1PO, D7S820, D13S317, D8S1179, D16S539, FGA, D18S51, TH01, D21S11, TPOX, D3S1358, vWA


3) Path: DNALocus/DNALocusTypeText

dnaLocusValue 1) Definition needed.


3) Path: DNALocus/DNALocusValue


PalmPrint 1) A representation or an encoding of the identifying characteristics of a person’s palm print.

2) Path: BiometricType



3) Path: Biometric/BiometricImage



1136

269

270

271

272

4.15.4 Domestic relations The structure of a Domestic Relations Case Type Specific Information will be included in other messages will be documented in this section. This describes the unique Domestic Relations case elements that are needed to initiate a case in the court records for a filing. This information is supporting primary transactions between the Filing Assembly MDE and the Filing Review MDE.

The following Domestic Relations cases supported are the following: Divorce, Separation, Child custody, Child support, Domestic Violence, Maternity, Paternity, and Adoption.

In a domestic violence case, the person seeking protection is the initiating party, the one against whom protection is sought is the responding party, children are other Parties.

In an adoption, the proposed adopting parent is the initiating party; the current parent is the responding party; the child is other Party.


4.15.4.1 Domestic relations Domain Model



1137113811391140

11411142

11431144

1145

1146

1147

1148

273

274

275

276

4.15.4.2 Domestic relations Data DictionaryClass Property or Reference Definition and Notes

DomesticCaseInformation 1) Definition needed.

2) Path: DomesticCaseType

3) Additional Notes: Extends CaseType

contestedIndicator 1) Whether a divorce is contested.


3) Path: DomesticCase/CaseContestedIndicator


causeOfActionCode 1) The legal ground on which the request for relief is based. This is the fourth level of case classification/type, for civil cases. Allowable values set forth in Court Policy.


3) Path: DomesticCase/CaseCauseOfActionCode


DomesticCasePersonInformation 1) Definition needed.


3) Path: DomesticCase/DomesticCasePerson

MarriageInformation 1) Definition needed.


3) Path: DomesticCase/DomesticCaseMarriage

DomesticViolencePetitionInformation 1) Definition needed.


3) Path: DomesticCase/DomesticCaseViolencePetition

ParentInformation 1) Definition needed.


3) Path: DomesticCase/DomesticCaseParentRelationship

DomesticCasePersonInformation 1) Definition needed.

2) Path: PersonType






3) Path: self (mapped to PersonType, see ExtendedPersonInformation tab)



1149

277

278

279

280


DomesticViolencePetitionInformation 1) Definition needed.

2) Path: DomesticViolencePetitionType

requestToVacateCode 1) Designation of place that abuser will be ordered to vacate. Allowable values to be set forth in Court Policy.


3) Path: DomesticViolencePetition/RequestToVacateCode


requestToVacateText 1) Open text designation of place that abuser will be ordered to vacate. This should contain a description of the place, and its location.


3) Path: DomesticViolencePetition/RequestToVacateText

stayawayDistanceText 1) Description of the distance abuser must maintain from abused person(s).


3) Path: DomesticViolencePetition/StayawayDistanceText

noContactCode 1) Means of communication with initiating party that the court is being asked to prohibit. Allowed values to be set forth in Court Policy.


3) Path: DomesticViolencePetition/NoContactCode


custodyDescriptionText 1) Description of temporary custody award that court is being asked to include in the order.


3) Path: DomesticViolencePetition/CustodyDescriptionText

childSupportDescriptionText 1) Description of temporary child support award that the court is being asked to order.


3) Path: DomesticViolencePetition/ChildSupportText

respondentDangerAlertIndicator 1) Definition needed.


3) Path: DomesticViolencePetition/RespondentDangerAlertIndicator


MarriageInformation 1) Definition needed.

2) Path: MarriageType

dateOfMarriage 1) Definition needed.


3) Path: Marriage/MarriageDate




281

282

283

284


dateOfDivorce 1) Definition needed.


3) Path: Marriage/DivorceDate


dateOfSeparation 1) Definition needed.


3) Path: Marriage/SeparationDate


DomesticCasePersonInformation (spouse)

1) Definition needed.


3) Path: Marriage/MarriageSpouseReference

4) Additional Notes: of type ReferenceType

ParentInformation 1) Definition needed.

2) Path: ParentRelationshipType

parentTypeCode 1) Type of parent. Allowed values set forth in Court Policy. Examples: natural, adoptive, surrogate.


3) Path: ParentRelationship/ParentTypeCode


DomesticCasePersonInformation (parent)



3) Path: ParentRelationship/ParentReference

DomesticCasePersonInformation (child)



3) Path: ParentRelationship/ChjildReference



1150

1151

285

286

287

288

4.15.5 Juvenile The structure of a Juvenile Case Type Specific Information will be included in other messages will be documented in this section. This describes the unique Juvenile case elements that are needed to initiate a case in the court records for a filing. This information is supporting primary transactions between the Filing Assembly MDE and the Filing Review MDE.

The following Juvenile cases supported are the following: Delinquency and Dependency.

In a juvenile delinquency petition, the state is the initiating party; the child is the responding party; the parents are merely information about the child unless state law makes them parties or other actors.

In a dependency case, the state is the initiating party, the child is the responding party, and the parents are other Parties.


4.15.5.1 Juvenile Domain Model

4.15.5.2 Juvenile Data DictionaryClass Property or Reference Definition and Notes

Act 1) Definition needed.

2) Path: IncidentType

actText 1) Legal term used to describe the alleged offense, which would be a crime if committed by an adult.


3) Path: Incident/ActivityDescriptionText

actSequenceNumber 1) The order in which this charge appears in a listing of multiple charges against the same juvenile. Example: Ordering charges in descending order of seriousness so that a case management application can identify the most serious charge.




1152115311541155

1156

11571158

1159

1160

1161

11621163

1164

289

290

291

292

3) Path: Incident/ActivityID



293

294

295

296


actDate 1) Definition needed.


3) Path: Incident/ActivityDate


Location 1) Definition needed.

2) Path: Incident/Location

JuvenileArrest 1) Definition needed.

2) Path: ArrestType

ArrestDate 1) The year, month, and day that the subject was arrested.


3) Path: Arrest/ActivityDate


ArrestTime 1) Time of an arrest.


3) Path: Arrest/ActivityTime

detaineeBloodAlcoholControlNumber 1) Sub Element and Definition Needed


3) Path: Arrest/ArrestBloodAlcoholContentNumberText

ArrestingOfficer 1) Definition needed.

2) Path: Arrest/ArrestOfficial


2) Path: Arrest/ArrestLocation

Booking 1) Definition needed.

2) Path: Arrest/Booking

arrestingAgencyCaseTrackingNumber 1) Definition needed.


3) Path: Arrest/ArrestAgencyRecordID/ID

ArrestingOfficer 1) Definition needed.

2) Path: EnforcementOfficialType



3) Path: EnforcementOfficial/PersonAssignedIDDetails/PersonOtherID/ID

badgeNumber 1) Definition needed.


3) Path: EnforcementOfficial/EnforcementOfficialBadgeID



297

298

299

300


arrestingAgencyORI 1) Official FBI-issued idenfifier for a law enforcement agency.


3) Path: EnforcementOfficial/PersonAssignmentUnit.Organization/OrganizationORIID/ID

arrestingOfficerUnit 1) Text description of the subdivision of the arresting agency. Example: Fairlawn precinct, Special Operations Division, Drug Task Force.


3) Path: EnforcementOfficial/EnforcementOfficialUnit/EnforcementUnitName

Booking 1) Definition needed.

2) Path: BookingType

bookingNumber 1) Number issued by booking agency at time of subject's entry into jail and maintained until release on all charges and sentences. New number issued for each subsequent jail stay.


3) Path: Booking/BookingAgencyRecordID/ID

bookingAgencyID 1) An alpha numeric identifier issued by the FBI to identify a specific criminal justice agency. In this instance the Law Enforcement Agency which booked the suspect into jail. (Ex. AZ0071300, etc.)


3) Path: Booking/BookingAgency/OrganizationID/ID

bookingAgencyName 1) The name of the Law Enforcement Agency which booked the suspect into jail.


3) Path: Booking/BookingAgency/OrganizationName

bookingDate 1) Definition needed.


3) Path: Booking/ActivityDate


bookingTime 1) Definition needed.


3) Path: Booking/ActivityTime

Custody 1) Definition needed.

2) Path: SupervisionType

custodyStatusCode 1) Definition needed.


3) Path: Supervision/SupervisionSubjectStatus/StatusText




301

302

303

304


detentionCenterID 1) Definition needed.


3) Path: Supervision/SupervisionFacility/OrganizationORIID/ID

DelinquentAct 1) Definition needed.

2) Path: DelinquentActType

delinquentCode 1) Sub Element and Definition Needed


3) Path: DelinquentAct/DelinquentActStatute/StatuteCodeID/ID, DelinquentAct/DelinquentActStatute/StatuteCodeSectionID/ID, DelinquentAct/DelinquentActStatute/StatuteOffenseID/ID

actLevelCode 1) Code identifying the level of the offense as defined in state law. Allowable values set forth in Court Policy. Example: Felony, Misdemeanor, Infraction, Ordinance Violation.


3) Path: DelinquentAct/DelinquentActClassification/DelinquentActSeverityText


actDegreeCode 1) Code indicating the degree of an offense as defined in state law. Allowable values set forth in Court Policy. Examples: First Degree Murder, Felony Type A/B/C.


3) Path: DelinquentAct/DelinquentActClassification/DelinquentActDegreeText


actGeneralCategoryCode 1) Code indicating the general category of the offense as set forth in state law. Allowable values set forth in Court Policy. Examples: Attempt, Conspiracy, Accessory before the fact, Accessory after the fact.


3) Path: DelinquentAct/DelinquentActClassification/DelinquentActApplicabilityText


actAggravatorCode 1) Code indicating the existence of a factor that, under state law, heightens the seriousness of the charge and would subject an adult to increase punishment. Allowable values set forth in Court Policy. Examples: Use of deadly weapon, use of gun.


3) Path: DelinquentAct/DelinquentActClassification/DelinquentActSpecialAllegationText


DependencyAllegation 1) The grounds for declaring a minor child to be a ward of the state because of the neglect or abuse of the minor child's parents or guardians.

2) Path: DependencyAllegationType



305

306

307

308


allegationCode 1) A code identifying a specific ground sufficient in law for declaring the minor child a ward of the state.


3) Path: DependencyAllegation/DependecyAllegationCode


allegationText 1) Legal term used to describe the ground on which the minor child can be declared a ward of the state.


3) Path: DependencyAllegation/DependecyAllegationText

JuvenileCase 1) Definition needed.

2) Path: JuvenileCaseInformationType

3) Additional Notes: extends CaseType

prosecutingAgencyCaseTrackingNumber 1) Definition needed.


3) Path: JuvenileCase/CaseParticipants/CaseProsecutionAttorney/CaseOfficialCaseID/ID

4) Additional Notes: could use an extension

Juvenile 1) Definition needed.


3) Path: JuvenileCase/JuvenileCaseJuvenile

4) Additional Notes: of SubjectType

Act 1) Definition needed.


3) Path: JuvenileCase/CaseIncident

JuvenileArrest 1) Definition needed.


3) Path: JuvenileCase/CaseArrest

DependencyAllegation 1) Definition needed.


3) Path: JuvenileCase/DependencyAllegation


2) Path: LocationType

Juvenile 1) Definition needed.

2) Path: SubjectType



309

310

311

312


juvenileID 1) This is the reference to the person element in the Review Filing.


3) Path: Subject/SubjectID/ID

stateCriminalID 1) Identifier assigned by state police or other statewide entity to link multiple cases to the same subject. Example: OBTS Number.

2) Path: Subject/PersonAssignedIDDetails/PersonStateID/ID

sexOffenderRegistrationID 1) Definition needed.


3) Path: Subject/RegisteredOffenderID/ID

personEmancipatedIndicator 1) Definition needed.


3) Path: Subject/PersonEmancipatedIndicator

gangAffiliation 1) Definition needed.


3) Path: Subject/PersonGangAffiliation

Custody 1) Definition needed.


3) Path: Subject/SubjectSupervision

ParentGuardian 1) Definition needed.


3) Path: Subject/SubjectParentGuardian

Placement 1) Definition needed.


3) Path: Subject/SubjectPlacement



3) Path: self (maps to PersonType; see ExtendedPersonInformation model for details)

OrganizationPlacement 1) Definition needed.

2) Path: OrganizationPlacementType

organizationOtherActorIDReference 1) The value of the Organization.ID property in the ReviewFiling message linking this organization to the appropriate other actor element.


3) Path: PlacementOrganizationID/ID



313

314

315

316


ParentGuardian 1) Information about the juvenile's parent(s) or guardian(s).

2) Path: ParentGuardianType



3) Path: GuardianIDReference

relationshipToJuvenileCode 1) A code describing the parent or guardian's relationship to the juvenile. Allowable values are set forth in court filing policy. Examples: Father, Mother, Guardian


3) Path: GuardianRelationshipCode


PersonPacement 1) Sub Element and Definition Needed

2) Path: PersonPlacementType

personOtherActorIDReference 1) Definition needed.


3) Path: PlacementPersonID/ID

Placement 1) Information about the person or organization orther than parent or guardian with whom the juvenile lives. Examples: Foster home, foster parents, state institution, hospital, shelter.

2) Path: PlacementType

placementTypeCode 1) Code indicating the type of placement. Allowable values set forth in Court Policy.


3) Path: Placement/PlacementTypeCode


placementStartDate 1) Date on which the placement commenced.


3) Path: Placement/PlacementStartDate


StatusOffenseAct 1) Definition needed.

2) Path: StatusOffenseActType

statusOffenseActCode 1) Code designating the statutory or ordinance section, the violation of which would not constitute a crime if committed by an adult (only if a juvenile).


3) Path: StatusOffenseCodeID/ID, StatusOffenseSectionID/ID, StatusOffenseID/ID




1165

1166

317

318

319

320

4.15.6 TrafficThe structure of a Traffic Case Type Specific Information will be included in other messages will be documented in this section. This describes the unique Traffic case elements that are needed to initiate a case in the court records for a filing. This information is supporting primary transactions between the Filing Assembly MDE and the Filing Review MDE.

The violation issuing agency is the initiating party; the suspect/defendant(s) is the responding party.


4.15.6.1 Traffic Domain Model



1167116811691170

1171

1172

1173

1174

321

322

323

324

4.15.6.2 Traffic Data Dictionary


Citation 1) Definition needed.

2) Path: TrafficCitationType

3) Additional Notes: extends CitationType

citationNumber 1) a sequential number preprinted on the citation form which serves as the ticket number


3) Path: TrafficCitation/ActivityID/ID

timeOfViolation 1) time of day that the citation was issued


3) Path: TrafficCitation/CitationViolation/ActivityTime

4) Additional Notes: TrafficCitationViolation of IncidentType

dateOfViolation 1) date of actual violation rather than citation issue


3) Path: TrafficCitation/CitationViolation/ActivityDate


dateOfCitationIssue 1) date citation was issued


3) Path: TrafficCitation/CitationViolation/IncidentResponse/ActivityDate


officialPresentForIncidentIndicator 1) Definition needed.


3) Path: TrafficCitation/CitationViolation/IncidentOfficialPresentIndicator

4) Additional Notes: from IncidentType

narrativeSummaryOfViolation 1) A narrative description of the facts and circumstances for which a citation was issued


3) Path: TrafficCitation/CitationViolation/ActivityDescriptionText


correctableOffenseIndicator 1) an indicator that equipment (tail light, headlight, etc.) requires fixing; if fixed, citation is dismissed


3) Path: TrafficCitation/CitationDismissalConditionIndicator

correctableOffenseText 1) text that equipment (tail light, headlight, etc.) requires fixing; if fixed, citation is dismissed


3) Path: TrafficCitation/CitationDismissalConditionText



1175

1176

325

326

327

328


Offender 1) Definition needed.


3) Path: TrafficCitation/TrafficCitationSubject

CitationCourtAppearance 1) Definition needed.


3) Path: TrafficCitation/CourtAppearance

ViolationLocation 1) Definition needed.


3) Path: TrafficCitation/CitationViolation/IncidentLocation


ViolatedStatute 1) Definition needed.


3) Path: TrafficCitation/CitationViolation/IncidentViolatedStatute


CitationAgency 1) Definition needed.


3) Path: TrafficCitation/CitationAgency

4) Additional Notes: of OrganizationType

DrivingIncident 1) Definition needed.


3) Path: TrafficCitation/DrivingIncident

CitationIssuingOfficial 1) Definition needed.

2) Path: TrafficCitation/CitationIssuingOfficial



lawEnforcementAgencyName 1) name of agency of charging law enforcement officer


3) Path: Organization/OrganizationName

lawEnforcementAgencyStation 1) name of an agency local office


3) Path: Organization/OrganizationUnitName

lawEnforcementAgencyReportingDistrict 1) Definition needed.


3) Path: Organization/OrganizationSubunitName

lawEnforcementAgencyORIID 1) ORIID of agency of charging law enforcement officer


3) Path: Organization/OrganizationORIID/ID



329

330

331

332


CitationCourtAppearance 1) Representation of when the offender is required to appear in court.

2) Path: CourtAppearanceType

dateOfCourtAppearance 1) Date on which defendant needs to appear at the court


3) Path: CourtAppearance/CourtAppearanceDate


timeOfCourtAppearance 1) Time at which defendant needs to appear at the court


3) Path: CourtAppearance/CourtAppearanceTime

CitationIssuingOfficial 1) Definition needed.

2) Path: EnforcementOfficialType

officerBadgeNumber 1) the badge number of the officer issuing citation


3) Path: EnforcementOfficial/EnforcemenOfficialBadgeID/ID

officerName 1) Definition needed.


3) Path: EnforcementOfficial/PersonName/PersonFullName

unavailableScheduleDescription 1) unavailable dates for officer issuing citation (e.g. due to vacation)


3) Path: EnforcementOfficial/EnforcementOfficialUnavailableSchedule

4) Additional Notes: include whole substructure, except Person


2) Path: EnforcementOfficial/PersonAssignmentUnitReference.Organization

ViolatedStatute 1) Definition needed.

2) Path: ViolatedStatuteType

offenseSectionID 1) alphanumerical reference indicating the statute violated within a charge code book.book.


3) Path: ViolatedStatute/StatuteCodeSectionID

offenseDescription 1) a description of the statute violated.


3) Path: ViolatedStatute/StatuteDescriptionText

offenseLevel 1) felony, misdemeanor, infraction


3) Path: ViolatedStatute/StatuteLevelText



333

334

335

336


ViolationLocation 1) Definition needed.

2) Path: LocationType

locationOfViolationFullAddress 1) the place where the violation occurred


3) Path: Location/LocationAddress/AddressFullText

locationOfViolationStreet 1) the street address where the violation(s) occurred


3) Path: Location/LocationAddress/Address/LocationStreet/StreetFullText

locationOfViolationCity 1) the city where the violation(s) occurred


3) Path: Location/LocationAddress/Address/LocationCityName

locationOfViolationState 1) the state where the violation(s) occurred


3) Path: Location/LocationAddress/Address/LocationStateName

locationOfViolationZipcode 1) the zip code where the violation(s) occurred


3) Path: Location/LocationAddress/Address/LocationPostalCodeID


SpeedRate 1) Structure to indicate the rate of speed at which something moves or moved, and in what units the rate of speed is measured.

2) Path: SpeedRateType

speed 1) Definition needed.


3) Path: (content)

4) Additional Notes: simple content extending decimal

unitDescription 1) Definition needed.


3) Path: SpeedRate/@rateUnitText



337

338

339

340


DrivingIncident 1) Definition needed.

2) Path: DrivingIncidentType

laserIndicator 1) an indicator that a laser gun was used to detect speed


3) Path: DrivingIncident/DrivingIncidentLaserDetectionIndicator

numberOfPassengersInVehicle 1) the number of people in the car not including the driver


3) Path: DrivingIncident/DrivingIncidentPassengerQuantityText

radarIndicator 1) an indicator that radar was used to detect speed


3) Path: DrivingIncident/DrivingIncidentRadarDetectionIndicator

accidentInvolvedIndicator 1) an indicator that the incident involved an accident


3) Path: DrivingIncident/IncidentCategory/IncidentTrafficAccidentInvolvedIndicator

propertyDamageIndicator 1) Indicator of whether property was damaged during the incident.


3) Path: DrivingIncident/IncidentDamagedProperty

4) Additional Notes: presence of this element indicates "true"

propertyDamageAmount 1) A monetary amount of property damage done during the incident.


3) Path: DrivingIncident/IncidentDamagedProperty/PropertyValueDetails/PropertyTotalDamageValue/PropertyValueAmount

4) Additional Notes: AmountType

injuryIndicator 1) Indicator of whether any person was injured during the incident.


3) Path: DrivingIncident/DrivingAccidentSeverityCode

fatalInjuryIndicator 1) Indicator of whether any person was fatally injured in the incident.




341

342

343

344


hazardousMaterialsIndicator 1) Indicator of whether hazardous materials were involved in the incident.


3) Path: DrivingIncident/DrivingIncidentHazMatText

4) Additional Notes: presence of this element indicates "true"

SpeedRate (speedLimit) 1) Definition needed.


3) Path: DrivingIncident/DrivingIncidentLegalSpeedRate

SpeedRate (offenderSpeed) 1) Definition needed.


3) Path: DrivingIncident/DrivingIncidentRecordedSpeedRate

Vehicle 1) Definition needed.


3) Path: DrivingIncident/DrivingIncidentInvolvedVehicle

ExtendedDriversLicenseInformation


2) Path: DriverAuthorizationType

licenseRestrictionCode 1) A code indicating driving restrictions placed on a driver.


3) Path: DriverAuthorization/DriverAuthorizationRestriction/DrivingRestrictionCode


licenseRestrictionText 1) Text description of driving restrictions placed on a driver.


3) Path: DriverAuthorization/DriverAuthorizationRestriction/DrivingRestrictionText

licenseRestrictionEndDate 1) The expiration date for driving restrictions that have been placed on a driver.


3) Path: DriverAuthorization/DriverAuthorizationRestriction/DrivingRestrictionEndDate


licenseIssueDate 1) Date on which the drivers license was issued.


3) Path: DriverAuthorization/DriverAuthorizationIssueDate




345

346

347

348


Insurance 1) Definition needed.

2) Path: InsuranceType

proofOfInsuranceIndicator 1) citing officer indicating there is proof of insurance


3) Path: Insurance/InsuranceActiveIndicator

proofOfInsuranceText 1) citing officer indicating there is proof of insurance by entering carrier name


3) Path: Insurance/InsuranceCarrierName

Vehicle 1) Definition needed.

2) Path: VehicleType

vehicleIdentificationNumber 1) manufacturer's identification number mounted on driver's side at the corner of the windshield and post


3) Path: Vehicle/VehicleID/ID

vehicleLicensePlateNumber 1) the license plate displayed on vehicle offender was driving


3) Path: Vehicle/VehicleLicensePlateID/ID

vehicleLicensePlateType 1) type of license plate displayed on vehicle offender was driving, i.e., commercial, truck


3) Path: Vehicle/VehicleRegistration/VehicleRegistrationPlateTypeCode

vehicleLicensePlateState 1) state that issued the license plate displayed on the vehicle


3) Path: Vehicle/VehicleRegistration/RegistrationJurisdictionCode.ncicLIS

vehicleMake 1) manufacturer's make of vehicle offender was driving


3) Path: Vehicle/VehicleMakeCode

vehicleModel 1) Definition needed.


3) Path: Vehicle/VehicleModelCode

vehicleYear 1) year that vehicle was manufactured


3) Path: Vehicle/VehicleModelYearDate



349

350

351

352


vehicleBodyTypeOrVehicleStyle 1) model described in terms of 2 door, 4 door, van, pickup, etc.


3) Path: Vehicle/VehicleStyleCode

vehicleColorCode 1) paint color of vehicle offender was driving when cited


3) Path: Vehicle/VehicleColorPrimaryCode


vehicleColorText 1) paint color of vehicle offender was driving when cited


3) Path: Vehicle/VehicleColorPrimaryText

Insurance (owner) 1) Definition needed.


3) Path: Vehicle/VehicleOwnerInsuranceCoverage

Insurance (operator) 1) Definition needed.


3) Path: Vehicle/VehicleOperatorInsuranceCoverage

Offender 1) Definition needed.

2) Path: CitationSubjectType

3) Additional Notes: extends SubjectType



3) Path: CitationSubject/PersonAssignedIDDetails/PersonOtherID/ID

bloodAlcoholLevelNumber 1) Definition needed.


3) Path: CitationSubject/PersonBloodAlcoholLevelNumber



3) Path: self (map to PersonType, see ExtendedPersonInformation tab)

ExtendedDriversLicenseInformation 1) Definition needed.


3) Path: CitationSubject/SubjectExtendedDriversLicenseInformation

4.16Implementation Notes

4.16.1 WebService ProfileThe WebService Profile specification is separate from this document, and examples are contained in that document.



1177

1178

11791180

1181

1182

353

354

355

356

5 References5.1 Normative

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[dateTime] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#dateTime, W3C REC-xmlschema-2, October 2004.

[FIPS 180-2] National Institute for Standards and Technology, Secure Hash Standard, http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf, August 2002.

[namespaces] T. Bray, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/, W3C REC-xml-names-19990114, January 1999.

[RFC2046] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, http://www.ietf.org/rfc/rfc2046.txt, IETF RFC 2046, November 1996.

[RFC4122] Leach, et al., A Universally Unique IDentifier (UUID) URN Namespace, http://www.ietf.org/rfc/rfc4122.txt, IETF RFC 4112, July 2005.

[XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), http://www.w3.org/TR/REC-xml/, W3C REC-XML-20040204, February 2004.

[XMLSIG] Eastlake, D., Reagle, J. and Solo, D. (editors), XML-Signature Syntax and Processing, http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, W3C Recommendation, February 2002.

[XMLENC] Eastlake, D. and Reagle, J. (editors), XML Encryption Syntax and Processing, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/, W3C Recommendation, December 2002.



1183

118411851186118711881189119011911192119311941195119611971198

11991200

12011202

357

358

359

360

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

http://www.w3.org/TR/REC-xml/

http://www.ietf.org/rfc/rfc4122.txt


http://www.w3.org/TR/REC-xml-names/

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

http://www.w3.org/TR/xmlschema-2/#dateTime


Appendix A. AcknowledgmentsThe following individuals were members of the committee during the development of this specification:

Greacen, John

Brooks, Rex

Hagler, Franklin

Roth, David

Harris, Jim

Perry, Ellen

Ensign, Chet

Bergeron, Donald

Schumacher, Scott

Goodwin, David

Gibson, Robin

Gilliam, Charles

Powell, Dallas

Poindexter, Gary

Taylor, Steven

Bousquin, Terry

Aerts, John

Johnson, Jerry

Smith, Christopher

Messing, John

O'Brien, Robert

Leff, Laurence

Rutkowski, Tony

Ruegg, John

DeFilippis, Robert

Clarke, Tom

March, Robert

Keane, James

Midstokke, Brad

Barlow, Jeff

Pope, Nick

Durham, Christopher

Slosberg, Mark

O'Day, Dan

Cover, Robin

Cabral, James

Clark, Jim

Smith, T

Welsh, D

Webster, Larry

Dillon, Ann

Wagner, Winfield



1203

1204

1205

1206

1207

1208

1209

1210

1211

1212

1213

1214

1215

1216

1217

1218

1219

1220

1221

1222

1223

1224

1225

1226

1227

1228

1229

1230

1231

1232

1233

1234

1235

1236

1237

1238

1239

1240

1241

1242

1243

1244

1245

1246

361

362

363

364

Kasselman, Pieter

Karotkin, Jeff

Martin, Roger

Plummer, Catherine

Tingom, Eric

Winters, Roger

Waite, Mike

Jensen, Allen

Clark, James Bryce

Chambers, Rolly

Cusick, James

Snowdon, Kyle

McElrath, Rex

Came, Scott

Fiore, Steven

Rutter, Nancy

Harrop, Jason

Morgan, Rockie

Cameron, Ockert

Oldenburg, Mark

Baker, Richard

Carlson, Tom

Sweeney, Ann

Sawka, Dan

Edson, Scott

Naidoo, Shogan

Beard, Jim

Alpert, Jed



1247

1248

1249

1250

1251

1252

1253

1254

1255

1256

1257

1258

1259

1260

1261

1262

1263

1264

1265

1266

1267

1268

1269

1270

1271

1272

1273

1274

365

366

367

368

Appendix B. Revision HistoryRev Date By Whom What

wd-01 2005-04-25 Eric Tingom Initial version

Wd-02 2005-05-17 Eric Tingom Updated Message Types

Wd-03 2005-06-05 Eric Tingom Message Profile WSDL Updated and Revised

Wd-04 2005-09-11 Eric Tingom Message Profile Removed to separate document. Modeling Updated for all message types, Major Design Elements, and Case Specific Information.



1275

1276

369

370

371

372

Appendix C. NoticesOASIS 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's procedures with respect to rights in OASIS specifications can be found at 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 implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Copyright © OASIS Open 2002. All Rights Reserved.

This 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 paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This 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 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



1277

127812791280128112821283

12841285

1286

128712881289129012911292

1293

129412951296

373

374

375

376

€¦ · Web viewwd-LegalXML-Specifications-01.doc. ... oasis-open.org?subject=Subscribe with the...

Documents

Transcript of €¦ · Web viewwd-LegalXML-Specifications-01.doc. ... oasis-open.org?subject=Subscribe with the...