Lessons Learned From the Development and Implementation of the

OASIS LegalXML Electronic Court Filing 3.0 Specification

Mr. James E. Cabral Jr., MTG Management Consultants, LLCMr. Rex McElrath, Administrative Office of the Courts of Georgia

September 6, 2006

GJXDM User’s Conference

25050\01\100929(ppt)

Agenda

Introduction

Architecture

IEPD Development

Implementation

ECF Road Map

35050\01\100929(ppt)

Introduction

Who Are OASIS and LegalXML?

What Does the Electronic Court Filing (ECF) Technical Committee (TC) Do?

What Happened to ECF 1.0 and 2.0?

What’s New in ECF 3.0?

How Does ECF 3.0 Relate to the GJXDM?

How Does ECF 3.0 Relate to the Justice Reference Architecture (JRA)?

45050\01\100929(ppt)

IntroductionWho Are OASIS and LegalXML?

LegalXML.org Community – 1998.

» Legal, court, business, academic, and technology professionals.

» Collaboration on nonproprietary standards for the legal community.

» Work Groups:

– Court Filing.

– Citations.

– Contracts.

– Horizontal – interoperability.

LegalXML Inc. – December 2000.

» Nonprofit corporation.

» Created to provide funding.

55050\01\100929(ppt)

IntroductionWho Are OASIS and LegalXML? (continued)

OASIS LegalXML Member Section – March 2002.

» Merged with Organization for the Advancement of Structured Information Systems (OASIS).

» Advantages:

– Funding, infrastructure, organization.

– Part of a recognized standards body.

– Proven open technical process.

– A broader community – ebXML, WS-Security, SAML, UBL, etc.

» Work Groups migrated to become TCs.

Active OASIS LegalXML TCs:

» ECF.

– Court Document Subcommittee.

» Integrated Justice.

» eContracts.

65050\01\100929(ppt)

IntroductionWhat Does the ECF TC Do?

From the ECF TC Charter:

» The TC develops specifications for the use of XML to create and transmit legal documents.

– From an attorney, party, or self-represented litigant to a court.

– From a court to an attorney, party, or self-represented litigant or another court.

– From an attorney or other user to another attorney or other user.

75050\01\100929(ppt)

IntroductionWhat Does the ECF TC Do? (continued)

From the ECF TC Charter:

» Because they are essential parts of the business model for electronic filing applications, the TC will also develop specifications for:

– Querying a court for data or documents.

– Expressing unique court policies and requirements.

– Providing legally sufficient service of court filings on other attorneys and unrepresented parties.

– Linking electronic documents to law firm and court case and document management systems.

– Sending and receiving payments associated with filings electronically.

– Providing appropriate security to ensure the confidentiality, authenticity, correctness, and completeness of the information transmitted.

85050\01\100929(ppt)

IntroductionWhat Happened to ECF 1.0 and 2.0?

Previous ECF TC specifications.

» ECF 1.0 (2000).

» ECF 1.1 (2001).

» Court Document 1.1 (2002).

» Query and Response (2002).

Status of previous specifications.

» All approved by the COSCA (Conference of State Court Administrators)/NACM (National Association for Court Management) Joint Technology Committee as “proposed standards.”

» All in use today by courts and vendors.

» None advanced by LegalXML for approval as “recommended standards.”

The latest ECF standard is 3.0, rather than 2.0, to reflect the linkage with the GJXDM 3.0.

Justice XML1.0/2.0

GJXDM3.0.x

ECF1.x

ECF3.0.x

95050\01\100929(ppt)

IntroductionWhat’s New in ECF 3.0?

Addresses new functional/nonfunctional requirements based on experience with ECF 1.x.

Supports Standards for Electronic Filing Processes (Technical and Business Approaches) approved in 2003.

Uses schema rather than DTD.

Leverages new and emerging standards.

» Vocabularies: GJXDM, UBL.

» Web services: W3C, OASIS, WS-I.

OASISOASIS

WS-IWS-I W3CW3C

UBLUBL

GJXDMGJXDM

ECF3.0

ECF3.0

105050\01\100929(ppt)

IntroductionWhat’s New in ECF 3.0? (continued)

Supports electronic service as well as electronic filing and electronic access to electronic court documents and data.

Includes the data elements needed to initiate new case filings for all types of cases.

Supports payments of fees and other court obligations.

Supports queries and court policy within the court filing specification.

Incorporates advanced features of document and message authentication, integrity, and security.

115050\01\100929(ppt)

IntroductionWhat’s New in ECF 3.0? (continued)

Supports some electronic service.

» Supported.

– Secondary Service – The delivery of copies of filed documents to persons who have already been made parties to a case.

» Not supported.

– Primary Service – The service of summonses, subpoenas, warrants, and other documents that establish court jurisdiction over persons, making them parties to cases.

125050\01\100929(ppt)

IntroductionWhat’s New in ECF 3.0? (continued)

Supports the following case types:

» Bankruptcy.

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

» Criminal (both felony and misdemeanor).

» Domestic relations, including divorce, separation, child custody and child support, domestic violence, and parentage (i.e., maternity or paternity).

» Juvenile (both delinquency and dependency).

» Traffic.

135050\01\100929(ppt)

IntroductionHow Does ECF 3.0 Relate to the GJXDM?

ECF 1.x was one of the bases for Justice XML 1.0.

The ECF TC represents courts on the Global XML Structure Task Force.

The ECF TC provides feedback to the GJXDM in the development of ECF 3.

145050\01\100929(ppt)

IntroductionHow Does ECF 3.0 Relate to the GJXDM? (continued)

GJXDM conformance is a core objective of ECF 3.0.

» Conformance is defined by the GJXDM Implementation Guidelines.

The GJXDM is most useful for describing:

» Common Objects – Person, Location.

» Justice-Specific Processes – Arrest, Booking, Jail, Prosecution.

The GJXDM is not as well developed for describing non-criminal information exchanges and processes.

ECF 3.0 uses the GJXDM version 3.0.3 where the structures and definitions correspond to the requirements of ECF 3.0.

155050\01\100929(ppt)

IntroductionHow Does ECF 3.0 Relate to the GJXDM? (continued)

ECF 3.0 messages use most GJXDM core components:

GJXDMCore

Components

Document

Incident

Location

Metadata

Organization

Person

Activity Arrest Case Citation Contact Information Court

Property Subject Supervision Vehicle Warrant

165050\01\100929(ppt)

IntroductionHow Does ECF 3.0 Relate to the JRA?

The ECF architectural strategies are being followed, in modified form, by Global for the JRA.

The strategies are being considered in some form by several groups:

» NIEM.

» Emergency Management.

» Several other possibilities.

175050\01\100929(ppt)

Architecture

Requirements.

Strategies.

Core specification.

» Major design elements (MDEs).

» Messages.

» Operations.

Service interaction profiles.

Document signature profiles.

Court policies.

185050\01\100929(ppt)

ArchitectureRequirements

The architecture must be flexible enough to support:

» Court-supported eFiling system.

» Vendor-supported eFiling system.

» Court-supported eFiling system that interfaces with vendor-based applications supporting some law firms.

» Many other possible combinations related to eService.

195050\01\100929(ppt)

ArchitectureStrategies

Separate architectural components.

» Core (messages).

» Service interaction profiles.

» Document signature profiles.

» Policies (human and machine).

Support for multiple technical solutions.

» Service interaction profiles (two so far).

» Document signature profiles (five so far).

205050\01\100929(ppt)

Architecture Strategies (continued)

Core specification.

» Defines the MDEs and the operations and messages that are exchanged between MDEs.

Service interaction profiles.

» Describe transmission system infrastructures that deliver messages between MDEs.

Document signature profiles.

» Describe mechanisms for signing electronic documents.

215050\01\100929(ppt)

ArchitectureStrategies (continued)

Standardized services – not applications.

» Four logical interfaces (MDEs).

» Messages grouped by logical interface.

» Interfaces may be grouped into applications as desired.

Standardized content.

» Mandate messages.

» Support extensions and constraints.

» Reuse GJXDM and UBL.

225050\01\100929(ppt)

The architecture divides the electronic filing process into four MDEs and describes the messages passed between each MDE.

ArchitectureMDEs

ServiceMDE

ServiceMDE

FilingAssembly

MDE

FilingAssembly

MDE

FilingReview

MDE

FilingReview

MDE

Court Record

MDE

Court Record

MDE

235050\01\100929(ppt)

Architecture MDEs (continued)

Filing Assembly MDE.

» Enables a filer to submit a filing and receive a response from the court.

» Supports service on other parties in the case.

Filing Review MDE.

» Enables a court to receive and review a filing message and respond to filers.

» Prepares filings for recording in its CMS and DMS.

» Enables filers to obtain court policies and status of filings.

ServiceMDE

FilingAssembly

MDE

FilingAssembly

MDE

FilingReview

MDE

FilingReview

MDE

Court Record MDE

245050\01\100929(ppt)

Architecture MDEs (continued)

Court Record MDE.

» Enables a court to record electronic documents and docket entries in its CMS and DMS and respond to the Filing Review MDE.

» Enables filers to obtain service information, case information, and documents.

Service MDE.

» Enables a party to receive service electronically from other parties in a case.

ServiceMDE

ServiceMDE

FilingAssembly

MDE

FilingAssembly

MDE

FilingReview

MDE

FilingReview

MDE

Court Record MDE

Court Record MDE

255050\01\100929(ppt)

ArchitectureMessages

A message stream contains:

» A required core message.

– Basic information common to all courts and case types.

» An optional case-type-specific message.

– Information appropriate only for a particular type of filing.

» An optional court-specific message.

– Information appropriate only for cases in a particular court.

Core MessageCore Message

AttachmentAttachment

AttachmentAttachment

Case-Type-Specific Message

Case-Type-Specific Message

Court-Specific Message

Court-Specific Message

ECF 3.0 Message Stream

265050\01\100929(ppt)

ArchitectureMessages (continued)

A message is an XML document transmitted between MDEs that validates against a message schema.

All messages are asynchronous.

» Supports SOA principle of stateless design.

A message may include binary-encoded documents.

» Embedded in the message using the GJXDM <j:DocumentBinaryData> element, or

» Included in one or more MIME attachments to the message stream.

275050\01\100929(ppt)

Architecture Operations

Operations are defined in the core specification, including:

» Operations supported by each MDE.

» The normal sequence of operations.

» Business rules for each operation.

285050\01\100929(ppt)

ArchitectureOperations (continued)

NOTE: The bold operations are required; the others are optional.

295050\01\100929(ppt)

Architecture Operations (continued)

Other query operations.

» GetFilingList.

» GetFilingStatus.

» GetCaseList.

» GetCase.

» GetDocument.

305050\01\100929(ppt)

ArchitectureService Interaction Profiles

Service interaction profiles support interoperability and reusability.

The core specification defines a comprehensive list of nonfunctional requirements for service interaction profiles and document signature profiles.

Each profile defines exactly how it meets and implements each nonfunctional requirement.

315050\01\100929(ppt)

Architecture Service Interaction Profiles (continued)

Each service interaction profile must support:

» Transport Protocol.

» MDE addressing.

» Operation addressing.

» Request and operation invocation.

» Synchronous mode response.

» Asynchronous mode response.

» Message/attachment delimiters.

» Message identifiers.

325050\01\100929(ppt)

Architecture Service Interaction Profiles (continued)

Each service interaction profile should support:

» Message non-repudiation.

» Message integrity.

» Message confidentiality.

» Message authentication.

» Message reliability.

» Transmission auditing.

335050\01\100929(ppt)

ArchitectureService Interaction Profiles (continued)

Current service interaction profiles.

» Web services (based on WS-I Basic Profile).

» Portable media (sneakernet).

Potential future service interaction profiles.

» HTTP (REST).

» MQ.

» ??

345050\01\100929(ppt)

ArchitectureDocument Signature Profiles

Each document signature profile must support:

» Signer name assertion.

» Signed date assertion.

» Multiple signatures.

355050\01\100929(ppt)

ArchitectureDocument Signature Profiles (continued)

Each document signature profile should support:

» Signer and date non-repudiation.

» Document integrity.

» Document signature auditing.

365050\01\100929(ppt)

ArchitectureDocument Signature Profiles (continued)

Currently defined document signature profiles.

» Null.

» XML Signature.

» Application-specific.

» Proxy and Symmetric Key (added).

Potential future document signature profiles.

» Password.

» Password/PIN.

375050\01\100929(ppt)

ArchitectureCourt Policies

Court policies supports customizations and local practices through:

» Human-readable court policy.

– May be HTML, text, or other document format.

– Court’s rules and requirements for electronic filing.

» Machine-readable court policy.

– Must be XML (an ECF 3.0 message).

– ECF 3.0 options supported in the implementation.

– Court code lists and extensions.

– Design-time and run-time information.

Courts should start with small core set of information and expand as semantics can support.

385050\01\100929(ppt)

ArchitectureCourt Policies (continued)

A human-readable court policy must include:

» The unique court identifier.

» The location of the machine-readable court policy.

» A definition of what constitutes a “lead document.”

» How to assign party and attorney identifiers.

» A description of how the court processes (dockets) matter.

» Any required elements that are optional in the schema.

» Any restrictions to property values other than code lists.

» Any other rules required for electronic filing in the court.

395050\01\100929(ppt)

ArchitectureCourt Policies (continued)

A machine-readable court policy must include:» Run-time information that will be updated from

time to time.– Code lists.

– Court’s public key for digital signatures and encryption.

» Development-time information that is not likely to change.

– The service interaction profile(s) that the court supports.

– The MDEs, operations, and case types supported by the court’s ECF 3.0 system.

– Whether the court accepts URLs, documents requiring filing fees, sealed documents, or multiple (batch) filings.

– Court-specific extensions, including required elements.

– The maximum sizes allowed for an attachment and a message stream.

405050\01\100929(ppt)

ArchitectureCourt Policies (continued)

The GJXDM extension mechanism is used to define elements in ECF 3.0 and courts may use that approach for local extensions.

However, the recommended approach for defining local extensions to ECF 3.0 is through a court-specific message.

» The court-specific message is described in court policy and is made up of name-value pairs.

» The name-value pairs must each include:

– Cardinality.

– A reference to the extension point in the core message or the case-type-specific message, expressed as an XPath substring.

» Conforming applications that do not understand the court-specific message may ignore the message and its content.

415050\01\100929(ppt)

ArchitectureLessons Learned

Separate functional and nonfunctional designs.

» Messages vs. service interaction profiles.

» Standardized services – not applications.

Leverage standards(e.g., GJXDM, UBL) for content.

Enclose documents with messages using MIME or DIME attachments rather than embedding.

Use the GJXDM extensions mechanism where possible, but multiple layers of extensions complicate interoperability.

Where appropriate, describe and enforce customizations in schema. Document the remaining customizations separately.

425050\01\100929(ppt)

IEPD Development

Requirements

Domain Modeling

XML Mapping

Schema Construction

Instance Generation

Packaging

435050\01\100929(ppt)

IEPD DevelopmentRequirements

Developed a comprehensive requirements document within a collaboration that included:

» National and state court leaders and technologists.

» Academics.

» Vendors of programs and systems for courts.

Used an object-oriented analysis and design methodology.

Focused on use cases to define the information exchanges.

» 26 core messages.

» 6 case-type-specific messages.

Defined targets of the messages within the logical system under design.

445050\01\100929(ppt)

IEPD DevelopmentDomain Modeling

Small teams built domain models for all 32 messages.

» Each team consisted of two to three SMEs and one modeler/ facilitator.

» Each message included definitions and constraints for all domain classes and elements.

» The domain models were described in UML using ArgoUML.

The ECF TC vetted each domain model.

455050\01\100929(ppt)

IEPD Development Domain Modeling (continued)

465050\01\100929(ppt)

IEPD Development XML Mapping

Modelers mapped most elements to GJXDM elements.

Payment-related elements were mapped to UBL elements.

The remaining elements were identified as extension schemas and mapped to base GJXDM types.

The primary mapping tools included:

» IEPD Mapping spreadsheet.

» Wayfarer.

475050\01\100929(ppt)

IEPD Development XML Mapping (continued)

485050\01\100929(ppt)

IEPD Development Schema Construction

Modelers generated the GJXDM subset schema using the Subset Schema Generator Tool (SSGT).

Constraints were applied to the subset using an XSLT script.

Modelers used XMLSpy to construct the remaining schemas:

» Common schemas (case, message, etc.).

» Code list schemas.

» Case-specific extension schemas.

» GJXDM-based document schemas for most messages.

» UBL-based document schemas for payment messages.

Schemas were validated in XMLSpy.

The ECF TC vetted each XML schema.

495050\01\100929(ppt)

IEPD Development Schema Construction (continued)

505050\01\100929(ppt)

IEPD Development Instance Generation

Modelers generated XML instances based on each of the 26 message schemas in XMLSpy.

Appropriate data was inserted to simulate real messages.

Instances were validated in XMLSpy and the GJXDM Validation Tool.

Instances are included in the specification but are non-normative.

515050\01\100929(ppt)

IEPD Development Instance Generation (continued)

525050\01\100929(ppt)

IEPD DevelopmentPackaging

The entire specification is packaged as an IEPD:

» art – graphics.

» mod – mapping spreadsheet.

» uml – domain model.

» xml – instances.

» xsd – schemas.

– Casetype.

– Codelist.

– Common.

– Constraint.

– Message.

– Subset.

» ecf-v3.01-spec-wd02.doc – specification.

535050\01\100929(ppt)

IEPD Development Lessons Learned

The MDE construct helped to focus the modeling. Pairing SMEs and modelers is essential for building a useful

domain model. A single IEPD for a group of related exchanges has:

» Advantages.

– Common objects/reuse.

– Packaging.

» Disadvantages.

– Complexity in normalization.

– Looser constraints.

545050\01\100929(ppt)

Implementation

Deployment process.

Pilot sites.

» Maricopa County, Arizona.

» Georgia.

555050\01\100929(ppt)

ImplementationDeployment Process

Assign MDEs to implementation subsystems and components.

Define service interaction (messaging) profiles to match to the messaging approaches used within application architecture.

Define document signature profiles.

Publish human-readable and machine-readable court policies.

Design, implement, and test court components.

» Filing Review MDE.

» Court Record MDE.

Recruit vendors to design, implement, and test their components.

» Filing Assembly MDE.

» Service MDE.

565050\01\100929(ppt)

ImplementationMaricopa County, AZ

Clerk of the Superior Court implementing a new electronic filing system to consolidate several existing systems.

» Designed as a multi-vendor system

» 3 vendors participating.

Implementing ECF 3.0 core specification Developing a custom web service service interaction profile.

» Will support chunking of attachments to avoid web server HTTP POST limits.

– Should the Web Service Serice Interaction Profile support chunking of attachments?

575050\01\100929(ppt)

ImplementationMaricopa County, AZ

Implementation Feedback

» Need query for filings/cases based on filing assembly MDE ( vendor) or filing status

» Can ECF 3.0 be used or extended to support Judge Review and approval of documents, draft orders, etc.?

585050\01\100929(ppt)

ImplementationGeorgia

Working with the Georgia Department of Human Resources Office of Child Support Services.

» Partner agency and highest volume filer for Georgia courts.

Using:

» Web Services Profile.

» XML Signature Profile.

» Majority of ECF 3.0 MDEs.

– Exception – Service MDE (partial implementation).

595050\01\100929(ppt)

ImplementationGeorgia (continued)

Implemented with the majority of MDEs in two system types:

» One located at Department of Human Resources.

» Other systems installed on appliance servers located at individual Superior Courts.

Implementing an XML Schema + XSL FO Style Sheet approach to documents to resolve issues with:

» Digital signatures and time stamps.

» Inconsistencies between XML data and PDF binary documents.

605050\01\100929(ppt)

ImplementationGeorgia (continued)

Successes in regard to ECF 3.0.

» Enabled transactional partnership between DHR and courts.

» Freed up 15 full-time employee positions per month by streamlining filing process on DHR side and 1 to 2 full-time employees per large Superior Court.

– 2-day process now accomplished within 12 to15 minutes, including preparation, approvals, transmitting, and docketing.

» Achieved successful interoperability between:

– Systems – IBM mainframe to PC-based.

– Databases – IBM DB2 and MS SQL Server to Btrieve-based flat file databases.

– Development Environments – Java to MS .Net.

615050\01\100929(ppt)

ImplementationLessons Learned

Courts are taking advantage of modular architecture.

Interoperability issues principally lie in the profiles.

» Low-level semantics problem solved by GJXDM.

» High-level semantics problem solved by defining reusable messages.

» “Nonfunctional” requirements present significant interoperability issues:

– Security, reliability, privacy, etc.

625050\01\100929(ppt)

ECF Road Map

3.03.01

3.1

4.0

635050\01\100929(ppt)

ECF Road Map3.0

Approved by the ECF TC as a “committee draft” in November 2005.

Accepted for review as “proposed standards” in December 2005 by the Joint Technology Committee of COSCA and NACM.

Beta use solicitation is under way for courts and vendors.

645050\01\100929(ppt)

ECF Road Map3.01

Minor updates to ECF 3.0.

Conformance with the OASIS Reference Model for Service- Oriented Architecture (SOA) and other emerging concepts in SOA.

655050\01\100929(ppt)

ECF Road Map3.1/4.0

More feedback from implementations.

Enhanced support for other case types.

» Appellate filings.

» Filings in administrative tribunals.

» Civil traffic.

» Parking.

» Local ordinance violations.

665050\01\100929(ppt)

ECF Road Map3.1/4.0 (continued)

Support for new use cases.

» Electronic service of process.

» Non-case-related filings into a court clerk’s office.

Updates to technology.

» Future releases of the GJXDM and the NIEM.

» XML court forms.

675050\01\100929(ppt)