This document defines the OASIS LegalXML Litigant Portal Exchange 1.0 (LPX 1.0) standard, which consists of a set of non-proprietary message specifications and data models, along with clarifying explanations, to promote interoperability between litigant portal systems, courts, legal assistance providers and related systems.

Status:

This document was last revised or approved by the OASIS Litigant Portal (LP) TC on the above date. The level of approval is also listed above. Check the "Latest stage" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=lp#technical.

TC members should send comments on this document to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/lp/.

This specification is provided under the Non-Assertion Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis-open.org/committees/lp/ipr.php).

Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

Citation format:

When referencing this specification the following citation format should be used:

[LPX-v1.0]

Litigant Portal Exchange Version 1.0. Edited by James Cabral, Jim Harris, Barb Holmes, and Riyaz Samnani. 06 August 2019. OASIS Committee Specification Draft 01 / Public Review Draft 01. https://docs.oasis-open.org/lp/lpx/v1.0/csprd01/lpx-v1.0-csprd01.html. Latest stage: https://docs.oasis-open.org/lp/lpx/v1.0/lpx-v1.0.html.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than 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 OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

Table of Contents

1 Introduction. 5

1.1 IPR Policy. 5

1.2 Terminology. 5

1.2.1 Key Terms and Definitions. 5

1.2.2 Symbols and Abbreviations. 7

1.3 Normative References. 7

1.4 Non-Normative References. 7

2 (Informative) Scope. 8

2.1 Functional Components. 8

2.1.1 Registration/Login. 8

2.1.2 Description/Navigation. 8

2.1.3 Problem Identification. 8

2.1.4 Solution Options. 8

2.1.5 Assistance. 9

2.1.6 Tradeoff Preferences. 9

2.1.7 Probabilistic Outcomes. 9

2.1.8 Capacity Assessment 9

2.1.9 Service Providers. 9

3 Operations. 10

3.1 Assistance. 12

3.2 Capacity Assessment 13

3.3 Case Search. 14

3.4 Description Navigation. 15

3.5 Jurisdiction. 16

3.6 Probabilistic Outcomes. 17

3.7 Problem Identification. 18

3.8 Provider Profile. 19

3.9 Registration Login. 20

3.10 Request Accommodation. 21

3.11 Solution Options. 22

3.12 Tradeoff Preferences. 23

3.13 User Profile Output 24

4 Conformance. 25

4.1 Portal Implementers. 25

4.2 Portal Partners. 25

Appendix A. Acknowledgments. 26

Appendix B. Revision History. 27

1 Introduction

This document is a specification developed by the OASIS LegalXML Litigant Portal Technical Committee (LP TC). It defines a set of components, operations and message structures for a litigant portal.

1.1 IPR Policy

1.2 Terminology

The key words "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] and [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2.1 Key Terms and Definitions

This section defines key terms used in this specification.

Anonymous Portal User

A Litigant Portal enables a user to use the portal anonymously without registering (see On-boarding, Registration/Login Module) but data entered is not saved for later use.

Assistance Module

The Assistance Module of the Litigant Portal determines from user responses to questions whether the user has a legal problem and whether the user should be referred to a legal or non-legal service provider for help in addressing it. If the user is not eligible for a legal referral or chooses not to accept an available referral, s/he is referred to the most cost-effective type of non-attorney assistance available. The user is linked to the type of assistance desired (see Solution Provider).

Automated Form

A form that is not static in design but is generated after the user completes an interactive interview to collect the variable information needed for the form. Generally, this will be generated by a system outside of the portal but may use data entered through user interaction and other session data.

Capacity Assessment Module

The Capacity Assessment Module of the Litigant Portal determines from user responses to questions the capacity of the user to use the services identified by the portal, such as literacy and language ability, need for an interpreter, computer literacy and access to a computing device and the internet, prior legal experience, immigration status (for immigration assistance), documentation of a user’s disability, and access to transportation if needed.

Data Transparency

A Litigant Portal provides assurance to the user that data provided by the user is being used to provide information in a reliable and understandable manner to achieve better outcomes and is not used outside the scope agreed to by the user.

Governance

A Litigant Portal is governed by a group of interested professionals and lay people sharing the goal of providing non-legal and legal information and resources to people seeking online assistance with perceived legal problems.

Description/Navigation Module

A Litigant Portal’s entry point provides descriptions of its modules’ capabilities and navigation to any module.

Inclusive Design

A Litigant Portal is designed to be accessible to and usable by as many people as reasonably possible without the need for special adaptation or specialized design. This extends the target market to include people who are less able and reduces the level of ability required to use the portal in order to improve the user experience for a broad range of customers and perceived legal problems.

Litigant Portal

A Litigant Portal is a website for people with a problem to determine what kind of problem it is and what kind of non-legal or legal resources are available. If the problem is legal, it will advise users on what are the most likely or common alternatives and actions for their type of problem, legal strategies and tradeoffs, and then develop a plan to address the problem.

On-boarding

The process for the governing body of the portal to add a trusted provider to be surfaced as a possible solution on the portal.

Probabilistic Outcomes Module

A Litigant Portal is designed to identify the most likely or most common actions and alternatives/ pathways in a case of a given type in the locality where historical data of a court or legal aid organization is captured, help a user determine the best course of action, and the outcomes of a variety of alternatives. Alternatives include lawyer referral, online self-help, or mediation. Historical case data of results in similar situations is segmented by claim type and amount, case type, level and jurisdiction of a court, and type and amount of judgment associated with a claim. Courts may track the percentage of judgments amounts paid and satisfied.

Problem Identification Module

A Litigant Portal is designed to prompt a user to describe the perceived legal or non-legal problem they have, and to suggest available legal strategies based on the user’s preferences for tradeoffs (see Tradeoff Preferences Module). The user may identify related issues, whether legal or non-legal, and timing/ urgency/ deadline issues and location/ jurisdiction issues.

Registration/Login Module

A Litigant Portal allows anonymous use with registration, but also provides a secure method of creating an account, recording the role the user will play in the perceived legal problem. Using an account saves the user’s information for later use. A user may register either as a user or as an intermediary facilitating access by a user.

Solution Provider

A Litigant Portal enables solution providers to make themselves available for referral to users based on issue type/ category and the provider’s capacity to handle a maximum number of referrals. A solution provider may offer one or more levels of service for legal or non-legal issues identified by the Problem Identification Module. A solution provider may have financial eligibility criteria for accepting a referral for a specified alternative/ pathway.

Solutions Module

Depending on the results of a user’s input to the Problem Identification Module, the Solutions Module suggests several generic non-legal solutions or, for a legal problem, available legal alternatives for which the user is eligible (see Probabilistic Outcomes Module). The solution may depend on the user’s preferences for in-person/ telephonic assistance, non-computer options, and use of a particular language. Financial eligibility for a solution may depend on income, expense, debt, public assistance and property ownership data. Other eligibility criteria may also be imposed by a provider.

Tradeoff Preferences Module

A Litigant Portal records a user’s preferences or requirements related to cost, speed (timing/ urgency/ deadline), convenience (location/ jurisdiction issues) and due process (exercising their legal rights). A user’s preferences will be used by Assistance and Solutions modules.

Warm Handoff

In a Litigant Portal a warm (seamless) handoff captures the information entered by the user for use during the referral and transmits it (with the user’s consent) to a resource who can provide the assistance needed without reentry of information.

1.2.2 Symbols and Abbreviations

This section defines key symbols and abbreviations used in this specification.

ECF

Electronic Court Filing

LPX

Litigant Portal eXchange

NIEM

National Information Exchange Model

OASIS

Organization for the Advancement of Structured Information Standards

XML

eXtensible Markup Language

1.3 Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

1.4 Non-Normative References

[Litigant Portal Requirements]

Building A Litigant Portal Business and Technical Requirements. Thomas M Clarke, Ph.D., November 2015, https://ncsc.contentdm.oclc.org/digital/collection/accessfair/id/375/.

2 (Informative) Scope

The LPX specification defines operations between Litigant Portal Modules as defined in the report titled “Building A Litigant Portal Business and Technical Requirements” [Litigant Portal Requirements]. The specifications are intended to support development and operation of a litigant portal by:

· defining structured interactions between modules in the portal,

· facilitating navigation between modules in the portal, and

· defining interfaces with external partners and resources.

Version 1.0 of the LPX standard defines messages and logical data models focused on business requirements. Future versions of LPX will define physical models and objects defined at a schema level with specifications to more readily support interoperability of litigant portal implementations.

2.1 Functional Components

Litigant Portal Modules defined in the above referenced requirements are mapped to corresponding functional components in the LPX specification. Additional components are included to represent external partners and resources that may also interact with a litigant portal.

2.1.1 Registration/Login

Litigants may use the portal anonymously by not registering or logging in. If users wish to save their inputs or outputs and return later, they must register in a way that enables identification of them in some unique way (although not necessarily in a way that permits actual identification of the person).

2.1.2 Description/Navigation

This module describes the capabilities of the portal and provides basic navigation to the desired module or between modules. Users may still enter other modules directly if they know how to get there. They may also navigate directly from one module to another module as desired. If the messages between the modules are designed to carry navigation information, this module may be unnecessary.

If the user opted to use a referral, the module captures the service provider’s acknowledgment and acceptance of the referral, and the outcome of the referral (like favorable or unfavorable resolution with or without litigation, or abandonment).

2.1.3 Problem Identification

This module prompts the user to describe their problem in a way that will enable the portal to determine if it is a legal problem. Of course, that determination is not entirely an objective one, so it is more a matter of suggesting available legal strategies when appropriate. The module will prompt for information that enables the portal to determine if it is a legal problem within the scope of the portal and maps the legal problem to a court case type. Location of the issues(s) will help the module determine jurisdiction, available remedies, and identify service providers. An urgency scale will help identify deadlines or time frames for action. Legal issues identified will be mapped to standardized lists, such as the National Subject Matter Index (NSMI) used by the legal aid community.

Again, there may be several possible case types or causes of action for a particular legal problem, so the module should suggest all alternatives and explain the tradeoffs. If there is not a legal problem, or not one that the portal can respond to, the litigant may still gain value by exercising the solutions module.

2.1.4 Solution Options

If the problem is a genuine legal problem, this module should suggest several alternative solutions, some of which involve the formal legal system and some of which do not. In both cases the module should provide appropriate tradeoff information to aid the litigant in making a choice. The module will take into account the user’s requirements or preferences for in-person assistance, non-computer options, telephonic assistance, and use of a particular language. Using income, expense, debt, public assistance and property ownership data, the module will assess the user’s eligibility for services requiring financial eligibility, and whether eligibility can be determined.

If the problem identified is not a legal problem, this module may suggest several generic non-legal solutions with an appropriate handoff.

2.1.5 Assistance

The assistance module will determine whether the litigant likely requires formal representation by a lawyer or not. If so, the portal will provide a set of possible sources of representation or other forms of legal assistance (like full or limited scope representation, paid or pro bono representation) with seamless hand offs to the selected resource. If a lawyer is not desired by the litigant, the module will determine the most cost-effective form of assistance required and hand off the litigant to that assistance seamlessly.

2.1.6 Tradeoff Preferences

This module assesses the litigant’s preferred tradeoffs between cost, time, convenience, and due process. The tradeoff information will be used by other modules to recommend solutions and types of assistance. Time factors include preference for speed, determination of urgency type, level and deadline(s) as stated by the user or determined by the system. Cost factors include the user’s preference for affordability and cost limitations. Convenience factors include the user’s preference for a simpler process or for exercising due process rights in court, including the predictability and enforceability of outcomes. The links between tradeoff preferences and portal recommendations will be reported transparently.

2.1.7 Probabilistic Outcomes

For court cases, this module provides descriptions of the most likely or common alternatives and actions in a particular type of case. It will also report probabilistic or statistical information on the likely outcomes of each alternative, based on historical court data, including court type and case type, claim type and amount, resolution or judgment type and amount, and amount of issue resolution or judgment paid. The Probabilistic Outcomes module will help the user determine the best course of action, or pathway(s) (i.e., lawyer referral, online self-help, mediation, etc.) to take.

2.1.8 Capacity Assessment

This module will assess the capacity of the litigant to both use the portal and to use various forms of assistance other than formal representation. Users will enter such information as immigration status, disabilities, language proficiency, computer literacy, technology availability, reading/ writing proficiency, and access to transportation, as input for the module to make a capacity assessment.

This module is optional because not all jurisdictions may choose to include this capability, some litigants may not want to be assessed, and the ability to validly and appropriately assess such capacity is still not well understood.

2.1.9 Service Providers

All messages are either between modules or with external service providers. These providers range from legal aid organizations, courts, and full representation lawyers to various types of limited scope representation, non-profit organizations, and online for-profit providers. All such providers must support two-way interactions with the portal modules. They will likely have to mark up their databases using the same standards-based XML that the portal uses to identify legal problems, actions, assistance types, and provider types.

3 Operations

This section details messages and content exchanged between components in a litigant portal and with external partners. This initial version of the LPX specification provides guidance on messages and logical data models addressing functional needs of litigant portal interfaces. They also assume provision for extensions with additional data elements that may be required in specific implementations. These standards do not dictate what protocols should be used to implement the defined messages or how to format message content/payload. It is expected that future versions of these standards will specify requirements for messaging and content in a manner that will more readily support interoperability between litigant portals and their partners.

All of the messages and information models presented in this section were developed using a UML modeling tool. A separate document generated by the modeling tool provides more detailed documentation. The generated HTML documentation is available via the "Additional artifacts" link on the front page.

The following high-level use-case diagram provides some context for use of the operations described in this section.

3.1 Assistance

Provides for input of the type of assistance needed and returns providers based upon that.

AssistanceInputMessage

AssistanceOutputMessage

3.2 Capacity Assessment

Provides for submitting aspects of a user’s capacity to use certain features of technology and program capacity.

CapacityAssessmentInputMessage

CapacityAssessmentOutputMessage

3.3 Case Search

Provides parameters to perform a court case search and return case data.

CaseSearchInputMessage

CaseSearchOutputMessage

3.4 Description Navigation

Provides for a referral to a specific provider and returns an acknowledgement of receipt.

DescriptionNavigationInputMessage

DescriptionNavigationOutputMessage

3.5 Jurisdiction

Assists the user in identifying the likely jurisdiction for their issue.

JurisdictionInputMessage

JurisdictionOutputMessage

3.6 Probabilistic Outcomes

Provides case data to assist in determining probabilistic outcomes based upon a selected solution and jurisdiction.

ProbabilisticOutcomesInputMessage

ProbabilisticOutcomesOutputMessage

3.7 Problem Identification

Provides potential legal issues involved based on user described problem.

ProblemIdentificationInputMessage

ProblemIdentificationOutputMessage

3.8 Provider Profile

Outputs provider specific information to assist in determining eligibility and capacity.

ProviderProfileOutputMessage

3.9 Registration Login

Provides for registering a user.

RegistrationLoginInputMessage

RegistrationLoginOutputMessage

3.10 Request Accommodation

Provides the ability to request an accommodation for use of a service dog, interpreter, etc.

RequestAccommodationInputMessage

RequestAccommodationOutputMessage

3.11 Solution Options

Captures specific aspects of the user’s situation that may have an influence on the solution selected. These include income, expenses, public assistance and the like.

SolutionOptionsInputMessage

SolutionOptionsOutputMessage

3.12 Tradeoff Preferences

Calculates the trade-offs in terms of cost, time, likelihood of resolution.

TradeoffPreferencesInputMessage

TradeoffPreferencesOutputMessage

3.13 User Profile Output

Outputs specific user’s characteristics for use by a referral system.

UserProfileOutputMessage

4 Conformance

Conformance with this version of LPX provides for two separate tracks, one for implementers of a Portal and another for Portal partners who may automate interactions with a portal.

4.1 Portal Implementers

For portal implementations, conformance requires implementation of a minimum combination of messages as described in Section 3 Operations. Messages supporting the following modules MUST be implemented:

· Registration/Login

· Description/Navigation

· Problem Identification

· Solution Options

· Assistance

Messages supporting the following modules MAY be implemented:

· Tradeoff Preferences

· Probabilistic Outcomes

· Capacity Assessment

4.2 Portal Partners

A legal service provider (or any other entity interacting with a Portal) may implement any combination of messages defined in the LPX specification.

Appendix A. Acknowledgments

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

Lester Bird, Pew Charitable Trusts

Greg Bloom, Individual

James Cabral, MTG Management Consultants

Ahbijeet Chavan, Tyler Technologies

John Chatz, HPE

Thomas Clarke, National Center for State Courts

Adam Earnheart, Tyler Technologies

Mark Gelade, Los Angeles Superior Court

John Greacen, Greacen Associates

Jim Harris, National Center for State Courts

Barbara Holmes, National Center for State Courts

John Matthias, National Center for State Courts

Amitabh Mukherjee, Microsoft

Snorri Ogata, Los Angeles Superior Court

Joyce Raby, Florida Justice Technology Center

Glenn Rawdon, Legal Services Corporation

Riyaz Samnani, IAALS

Alex Zilberfayn, Individual

Appendix B. Revision History

Revision	Date	Editor(s)	Changes Made
v1.0-wd01	08-Oct-2018	Jim Harris	Initial draft
v1.0-wd02	04-Feb-2019	Jim Harris	Updates to module descriptions, message content details, and conformance clause.
v1.0-wd03	04-Jun-2019	Jim Harris Barb Holmes	Updates to definitions, module descriptions, message content details, and information model references.
V1.0-wd04	29-Jun-2019	Jim Harris Barb Holmes	Updates to provider and user profiles, module definitions and embedded PDF of UML documentation generated by BOUML.