Florida Courts Technology Standards
Section V
Court Application Processing System

5.0.0 | SECTION 5 INTRO

The Florida Courts Technology Commission (“FCTC”) adopts this Functional Requirements Document (“FRD”) to provide specifications for Court Application Processing Systems (“CAPS”) to coordinate the use of information technology and electronic case files, in court and in chambers, by trial court judges and staff. In addition to the functional requirements outlined in this document, systems must comply with applicable Florida Rules of General Practice and Judicial Administration, and other technical and functional standards established by the Court that may apply to CAPS.

5.1.1 | CERTIFICATION REQUIRED

Any system meeting the definition of CAPS in this section must be certified under Section 5.2, Certification below before being deployed, renewed, or substantially modified. Each circuit determines which certified system best meets its needs. The chief judge’s approval shall be required before the purchasing or upgrading of any system.

5.1.1.1

Certification may only be granted when a product or combination of products meets or exceeds the functional standards specified in this document unless excluded.

5.1.1.2

The system shall meet the general criteria of 6.3 and perform each of the following functions, as specified in the sections cited, and be accessible in a seamless program via a single log on:

• Calendar (5.4);
• Search (5.5);
• Case Management and Reporting (5.6);
• E-Notification of Data Issues (5.7);
• Orders (5.8);
• Case Notes (5.9); and
• Help (5.10).

5.1.2 | CAPS DEFINITION

CAPS is defined as a computer application designed for in-court and in-chambers use by trial judges, their staff, and Court Administration personnel to access and use electronic case files and other data sources in the course of managing cases, scheduling, and conducting hearings, adjudicating disputed issues, and recording and reporting judicial activity.

5.1.3 | EXCLUSION FOR CLERK’S RESPONSIBILITIES

The FCTC recognizes that existing law establishes the clerks of court as the official custodians of court records. Systems built and maintained by the clerks of court and limited to their historical functions are excluded from this definition. Specifically, general-purpose files, indexes, or document viewers made available by the clerk to users other than the judiciary and in-court participants are not subject to the functional requirements of this document, although they remain subject to all other FCTC policies and requirements, including but not limited to the Integration and Operability standards and all other requirements set forth by the Supreme Court. This standard does require the clerks of court to make their official court files available to the CAPS in read-only fashion in real-time or from a replication delayed no more than five minutes from real-time.

5.1.4 | MANDATING CAPS

A CAPS shall be made available to the trial courts of this state, in every division, county, and circuit. The CAPS shall accept and display case information from the clerk’s case maintenance system (“CMS”) in form and function consistent with these functional requirements.

5.2.1 | VENDOR PRODUCT CERTIFICATION

A product offered by a single commercial vendor must be certified by the FCTC under this section before the vendor may sell or otherwise deploy a new installation, or renew a contract for an existing installation, as meeting the definition of CAPS in Section 5.1.2. When a vendor obtains certification for a product, the State Courts Administrator is authorized to enter into such agreements as she deems advisable to facilitate transactions between such vendor and any trial court unit that chooses to purchase the certified product.

5.2.2 | GENERAL SYSTEM CERTIFICATION

Any CAPS product or system that is not subject to the vendor product certification section requires general system certification before a new installation or deployment. General system certification can be granted for:

5.2.2.1

Internally developed systems that comply with the functional requirements of this document; or

5.2.2.2

Aggregated systems, consisting of components that individually may not meet the functional requirements but taken together do satisfy the requirements.

5.2.3 | PROVISIONAL CERTIFICATION

Provisional certification is for six months and may be renewed at the discretion of the FCTC. It may be granted for:

5.2.3.1

Partial systems or subsystems that meet only a part of the standards when a plan for attaining certification within a reasonable time has been approved by the FCTC;

5.2.3.2

Systems that lack specific data reporting requirements because the local clerk’s office does not maintain that data and it is not otherwise reasonably available from machine-readable sources; or

5.2.3.3

Any other partially compliant subsystem. Approval will be on a case-by-case basis under the procedures outlined in Section 5.2.5.

5.2.4 | EXISTING INSTALLATIONS

An existing system requires certification upon the earliest of the following events:

5.2.4.1

Substantial modification of the system; or

5.2.4.2

Expiration of the contracts under which any vendor provides the system or a subsystem.

5.2.5 | CERTIFICATION PROCESS

The certifying entity is the FCTC. The FCTC delegates its authority to make initial certification determinations to the State Courts Administrator.

5.2.5.1

Administrative Decision. The FCTC shall issue certification or notice that certification has been denied, within a reasonable time. Unless an interested party files a written application for review within thirty days of the FCTC’s decision, that decision will constitute the final decision of the FCTC.

5.2.5.2

Review and Final Action. A review of any disputed certification decision is conducted by a subcommittee of the FCTC appointed by its Chair for that purpose. The subcommittee’s decision shall constitute final action unless, within 30 days of its rendition, the FCTC adopts a resolution accepting review of the certification decision.

5.3.1 | PERFORMANCE

The system must meet or exceed the efficiencies delivered by conventional paper systems or previous electronic systems.

5.3.2 | ROBUSTNESS

The system must be engineered so that it does not break down upon foreseeable peaks of usage, user error, data corruption, or other stress. The system’s design must provide redundancy to eliminate a single point of hardware failure from interrupting CAPS availability to the court users.

5.3.3 | COMPATIBILITY

The system must be adaptable at a reasonable cost to be compatible and interoperable with any of the clerks of court systems being used in the state. It must use, to the extent feasible, industry-standard document formats and transmission protocols, and avoid all use of proprietary formats, data structures, or protocols.

5.3.4 | ADAPTABILITY

The system must be designed in a way that anticipates obsolescence of hardware and software and is upgradeable and modifiable as new technologies become available or statutes, rules, or court procedures change. In particular, the system must be able to accommodate, at a reasonable expense, additional data elements for specific divisions of court as adopted by the FCTC.

5.3.5 | ACCESSIBILITY AND SECURITY

The system must prevent access by unauthorized persons and facilitate access by authorized persons according to a defined set of user permission levels. The system must be usable by judges, and also by judicial assistants, clerks of court, and case managers as the judge may direct.

5.3.5.1 Security.

The system must comply with industry-standard security methods, including encryption and authentication protocols, to protect access to the application and associated data.

5.3.5.2 User Permission Levels.

• System-assigned User Permission Levels. The system shall provide the system administrator with the ability to configure user permissions to restrict access to the application, sub-applications (functions), and case data (as needed to comply with statutory restrictions on access to case data).

• The system shall provide a means for a judge to manage which other authenticated individual users or judge-defined user groups may view or change case-related information the judge originates, such as notes, document annotations, contents of work folders, case management information, and personal and system calendar entries.

5.3.5.3 Password Protection.

The system must authenticate users and their permission levels based on username and password, providing access to all functional modules using the same credentials.

5.3.5.4 Electronic Signatures.

The system must ensure that electronic signatures may be applied to orders only by the authenticated user.

5.3.5.5 Remote Access.

The system must be accessible remotely via the web by judges and other personnel having appropriate permission levels.

5.3.5.6 Persons with Disabilities.

The system must comply with Section 508 of the Rehabilitation Act of 1973 (as amended), which lists standards necessary to make electronic and information technology accessible to persons with disabilities.

5.3.6 | EXTERNAL DATA ACCESS

The system must allow access to the database(s) of the clerk(s) of court in the circuit to avoid any unnecessary re-keying of data by court personnel. It must be able to retrieve basic case information, any scheduling or calendaring information the clerk may maintain, the clerk’s progress docket, and the set of electronic documents that constitute the official court file.

5.3.7 | GLOBAL NAVIGATION

Each top-level module of 5.1.1.2 shall be accessible from any non-modal screen in the application by clicking once on a global navigation menu.

5.3.8 | HARDWARE INDEPENDENCE

The system must be reasonably hardware-independent and must work with a touch screen, mouse, or other pointing devices, or keyboard entry.

5.3.9 | PRINTER-FRIENDLINESS

All displays of case data or document images shall be printable, using either a screen print function or a developed printer-friendly routine. When a document is being displayed, the court shall have the option to print one or more pages at once.

5.3.10 | DISASTER PREVENTION AND RECOVERY STRATEGY

The system must use reasonable measures to prevent service interruption and have a plan for the continuation of operations if an interruption occurs. It must be designed to minimize the risk of data loss, including but not limited to secure, regular, and redundant data backup.

5.4.1 | CALENDARING SYSTEM REQUIRED

A system must include a planning and calendaring function that permits the court to allocate blocks of future time for specific purposes, that permits the court or authorized other persons to book specific hearings or other events into allocated time, and that displays or prints the schedule for a day, week, or month with the appropriate level of detail. Each schedulable block and event must also be able to be canceled by an authorized person as determined by the presiding judge/magistrate.

5.4.2 | PLANNING FLEXIBILITY

The system must accommodate docket planning using either time-certain or multiple-case-docket approaches, or such other approach as the court may specify. It must permit the court to specify the capacity of any multiple case docket and displays must be able to show the portion of capacity remaining.

5.4.3 | CALENDAR CONTROL

The calendaring system must prevent a user from inadvertent double booking a hearing for the same time slot that is not a mass docket or intentionally double booked. It must also prevent booking a multiple case docket in excess of its capacity unless the user deliberately overrides the capacity.

5.4.4 | REPLICATION

The system must permit the court to allocate blocks of time on a recurrent basis (e. g. every other Thursday or every fifth Friday) with minimum data entry. It must also be able to call up a list of cases based on defined criteria and schedule or reschedule all of the cases simultaneously into a new time block.

5.4.5 | EXTERNAL USER ACCESS

The system must be capable of displaying allocated time blocks to external users such as attorneys or parties as the judge may direct and must also provide a means by which the external users can either request to book a hearing into an allocated time block, or automatically and directly book a hearing into an allocated time block, as the judge may direct.

5.4.6 | DIRECT ACCESS TO CALENDAR MANAGEMENT

The calendar display screens must provide direct access to functions by which a judge, judicial assistant, or case manager can directly and immediately manage the court’s calendar with minimal click count, including set, re-set, continue, or cancel hearings or trials; and add a case to or remove a case from a docket.

5.4.7 | AUTOMATIC NOTATION AND NOTIFICATION

The system shall, as directed by the judge, create immediate automatic e-mail alerts to parties, or paper copies and envelopes to parties without an e-mail address, attorneys, clerks of court, case managers, court staff, whenever a calendared event is changed on a calendar by a judge, judicial assistant, or case manager.

5.4.8 | CALENDAR DISPLAY (INTERNAL)

The calendaring system shall contain a general-purpose calendar viewing function for internal users that displays allocated time blocks, any appointments scheduled within those blocks, and any unallocated time as the user may select.

5.4.8.1

The displayable fields shall be at least: hearing type; case type; case name; case number; date; time; judge; parties; attorneys; location (court and hearing rooms) and case age.

5.4.8.2

The fields displayed shall be limited appropriately by the user’s permission level. The display must have the ability to sort and filter by any displayed field.

5.4.8.3

When a specific appointment is listed on the display, clicking on the time and date portion shall call a function that permits editing, canceling, or rescheduling the event without retyping identifying information. Clicking on the case name will bring up a case calendar display (Section 5.4.9). There shall also be a control that opens the progress docket (Section 5.5.5).

5.4.8.4

When an allocated but still available time block, or any portion of unallocated time, is listed on the display, clicking on it shall call a function that permits entry of a new matter into that time block.

5.4.9 | CASE CALENDAR DISPLAY

The system shall have the ability to list all events (past and future) scheduled in a specific case.

5.4.10 | DAILY EVENT OR REMINDER

The calendaring function must support the daily reminder function of the case management module 5.6.4 by accepting items posted to a specific date without a specified time, for use as a reminder or tickler system.

5.4.11 | CALENDAR EXPORT

The system must be able to export calendaring information in industry-standard formats (e.g., iCalendar and Outlook).

5.5.1 | CASE SEARCH AND DISPLAY

The system must be able to retrieve and display basic case information from the clerk of court’s database and from any internal database it maintains. Basic case information includes at a minimum: case style (parties names, case number, and division of court); type of case; date opened; current status; identities, roles, and contact information of parties and attorneys.

5.5.2 | CASE SEARCH KEYWORDS

The system must be able to search for cases by case number, party name, party role, case filing date or date range, case type, or a combination of these fields.

5.5.3 | LOOKUP RETURN

The result of a lookup function must return either a list of cases meeting the search criteria, a Basic Case Information display screen if only one match was found, or a notification that no cases were found.

5.5.4 | CASE INFORMATION

A Case Information display must contain at least:

5.5.4.1

Basic Case Information and appropriate subsets of the events scheduled in the case and of the clerk’s progress docket.

5.5.4.2

Controls that call:

• the full progress docket;
• display of detailed information including a search for related cases on a party, attorney, witness, or another participant;
• an e-mail window pre-addressed to all the parties or attorneys in the case;
• a button that opens the scheduling function (and remembers the current case);
• a control that opens the list of orders that the system can generate; and
• a search window permitting single word and multiple word searches of the searchable electronically filed documents in the case, returning a subset of the progress docket containing the search terms.

5.5.5 | CLERK’S PROGRESS DOCKET

The clerk of court progress docket is a list of the documents in the official court file for the case. It is the most common entry point for the display of the contents of the court file. The court application must display the docket sequence number for each docket entry in the progress docket.

5.5.5.1

Each electronically filed document listed on the progress docket must have a link or button that immediately opens the document for viewing. It must be able to retrieve and display the documents and associated sequence number without unnecessary delay.

5.5.5.2

The progress docket must list the documents filed in the case in such a way as to readily distinguish, via icons or color-coding, electronically field documents from those which have been filed in paper form and not converted.

5.5.5.3

Orders must similarly be distinguished from motions and other filings.

5.5.5.4

There must be a word search function for the progress docket.

5.5.6 | DOCUMENT IMAGE DISPLAY

The system must display multiple documents from the clerk’s official court files consistent with time standards adopted by the FCTC.

5.5.6.1

The CAPS must be capable of displaying up to three document viewing workspaces side-by-side. The purpose of having up to three open workspaces is to allow the user to view either three different documents or three pages of the same document at the same time. The first viewing workspace will be referred to as the initial workspace, the second and the third viewing areas will be called the second and the third viewing workspace respectively. The initial viewing workspace shall open first, and the second and third workspace viewing areas shall open as the second and third documents are loaded for display. Each workspace must contain a control for paging the document forward or back.

5.5.6.2

A document being opened for viewing must open in the next available workspace to the right of the last viewing workspace opened. If all workspaces are in use displaying a document, the document shall open as a tab in the initial workspace, or via a horizontal scrolling in the same viewing area.

5.5.6.3

The workspace viewing area must contain controls that zoom, shrink, rotate or flip the document they contain.

5.5.6.4

The display must afford the user an option to specify user settings that identify the documents that can automatically be pre-loaded by default into three display workspaces when a case is opened for viewing.

5.5.6.5

The system must automatically adjust page workspace viewing area sizes to fit the monitors on which the documents are displayed. For example, smaller monitors would only need to be able to automatically display two workspace viewing areas rather than three.

5.5.6.6

Variances from these display standards are permitted for tablets and mobile devices to allow for effective use of their smaller displays.

5.5.7 | WORD SEARCH

The system must be able to search the contents of the documents in the official court files of a single case or multiple cases selected according to limiting criteria, including division of court, date range, related cases of a party, attorney, or other participant, charges or causes of action, and document type.

5.5.8 | ACCESSING EXTERNAL DATA

The system must make reasonable use of available sources of machine-readable data, organized into a display format useful to the court. It must contain a direct means for accessing legal research providers including but not limited to Westlaw and Lexis-Nexis.

5.6.1 | REPORTING

The system must have a comprehensive reporting function for case management data and must be flexible to meet the reporting needs of individual circuits or counties. At a minimum it must provide:

5.6.1.1

Active Case List, including title, type, age attorneys or firms, next scheduled event date, and time since last activity with the ability to sort and filter on any field.

5.6.1.2

Critical Case List, including a listing of cases by type which is near or has exceeded Supreme Court time standards for such cases.

5.6.1.3

Inactive Case List, including a listing of cases with no activity for 180 days; with motions filed but not set for hearing; with no service of process after 120 days.

5.6.1.4

Pending Orders List, containing cases having matters held under advisement by the judge, with the number of days since being placed in a work queue, see Section 5.6.3.

5.6.1.5

List of Cases on Appeal, if the data is retrievable from the clerk’s database.

5.6.1.6 Performance Measures.

The system shall have the ability to report the clearance rate of cases, age of pending cases, and time to disposition of cases.

5.6.2 | WORKFLOW MANAGEMENT

The workflow management system shall contain a work queue for each internal user and a due date monitoring system.

5.6.3 | WORK QUEUE

The system shall have a function for tracking the court’s work queue.

5.6.3.1

The judge, when viewing a document or a progress docket, shall have the ability to place a reference to the document directly into the work queue for subsequent action, with the ability to over-ride default due date or such other due date the judge may select.

5.6.3.2

The work queue shall also accept other manually entered items.

5.6.3.3

Each work queue must be able to accommodate the classification of work queue items into separate item types, such as proposed orders, internally generated orders, requests for domestic violence injunctions, warrants, emergency motions, and other user-specified types.

5.6.4 | DAILY REMINDER (TICKLER)

The system shall have a function for tracking due dates of specified tasks.

5.6.5 | ALERTS

The system must afford each user the ability to specify (and edit) a watch list of cases, sending an alert (electronic notification) advising that there has been a new filing or entry posted within the last twenty-four hours to the progress docket of any case on the user’s watch list.

5.6.6 | AUTOMATED TASK FOR CASE MANAGEMENT

The system must be able to run automated tasks that provide case management functions for the court, enabling the court to perform a SQL like query of any of the available data elements and populate form orders for each returned result.

5.7.1 | E-NOTIFICATION OF DATA ISSUES

5.7.1 E-Notification of Data Issues

CAPS shall provide the user a button that, when clicked, creates a communication to the clerk of court office for review of that case in question.

5.7.1.1

The communication should auto-include the case number in question.

5.7.1.2

The communication should provide an editable text field in which the user can describe the issue.

5.7.1.3

The CAPS shall maintain a record of communications generated and conveyed to the clerk of court for review.

5.7.1.4

An e-mail generated automatically from within the CAPS is an acceptable solution.

5.7.1.5

Each communication should include:

• the user reporting the issue;
• the case number in question;
• the issue to be reviewed (e.g., a case is pending in error); and
• a date and time stamp memorializing the time of the transmission.

5.7.1.6

Communications should be able to be easily aggregated for periodic transmission (e.g., a flat file).

5.8.1 | ORDER GENERATION AND PROCESSING REQUIRED

The system shall have the capacity to generate court orders by merging information from the accessible databases and runtime user input into a bank of forms. The CAPS shall permit editing of the proposed order and file the signed order in PDF/A format.

5.8.2 | RECALLABLE ENTRIES

The order generation subsystem shall be able to recall previous entries by the same user to avoid the necessity of re-keying content.

5.8.3 | PORTAL INTEGRATION

The CAPS shall permit proposed orders to be received through the Florida Court’s E-Filing Portal (“Portal”) and shall permit signed orders to be filed directly to the clerk’s CMS or Portal and served through the Portal, CMS, or CAPS.

5.8.4 | DOCUMENT MODELS

The document model for the order generation function must not be proprietary. Neither the court nor any county may be prevented from building or customizing their own form banks.

5.8.5 | TEMPLATES

The order generation function shall permit the court to generate orders from templates that merge, case style, case data, signature lines, distribution list data, and free text with the template.

5.8.6 | ELECTRONIC SIGNATURES

The order generation function must support the electronic signing of documents that results in a signed PDF document from either an internally generated or submitted proposed orders.

5.8.6.1

Unless a document is signed when generated, it shall be placed in the judge’s work queue.

5.8.6.2

The court must have the option of electronically signing some, all, or none of the documents in the work queue at the same time.

5.8.6.3

The subsystem must have a means for rejecting proposed orders submitted for signature with an explanation of the reason for rejection.

5.8.6.4

An electronic signature of a judge shall be accompanied by a date, timestamp, and case number. The date, time stamp, and case number shall appear as a watermark through the signature to prevent copying the signature to another document. The date, time stamp, and case number shall also appear below the signature and not be obscured by the signature.

5.8.7 | ELECTRONIC FILING AND SERVICE

The system shall effectuate electronic filing and service of orders according to the Florida Rules of General Practice and Judicial Administration.

5.9.1 | CASE NOTES

The system shall have a case note function that accepts input from internal users and may be viewed only by authorized personnel.

5.9.2 | CASE NOTES

The subsystem shall accept note entries through text entry and insofar as feasible shall be compatible with speech-to-text utilities.

5.9.3 | CASE NOTES

The subsystem shall be capable of accepting and storing documents or scanned images as part of the case notes.

5.9.4 | CASE NOTES

When a case note is originally entered from a document viewing screen, the case note must be able to recall the same document when the note is later viewed.

5.9.5 | CASE NOTES

The system shall automatically document the following in an audit log: scheduling events, changes to scheduled events, orders and judgments stent from the system, and the name of the user who initiated the entry or generated the order or judgment.

5.10.1 | HELP

The system must have a help system that adequately provides tutorials and documentation for users.

5.10.2 | HELP

There must be a control on every screen other than a modal window that can access the help menu.

5.10.3 | HELP

The help menu must describe how to use each component of the system.

5.10.4 | HELP

The help menu must contain a feedback channel for alerting system administrators of any performance issues or other problems.

Congratulations! You're now booked up on Section V from the Florida Courts Technology Standards!

You might need to reference it during your pursuit of justice.

For instance, you might need to examine this handbook in order to protect yourself from organizations/judges/lawyers who break the law (see this example of a Florida judge who outright committed perjury).

Nevertheless – and as always – please get the justice you deserve.

Sincerely,

www.TextBookDiscrimination.com

	Download
	FCHR 101: How it Works
	Audio: Drop the Steal
	Video: A Judge's Perjury
	A Judge's Perjury
	How-To: Disqualification
	Warning: FCHR Bribery
	Warning: FCHR Corruption
	Warning: FCHR Discrimination
	Warning: FCHR Obstructions

	Shop \| TBD Marketplace™
	Buy \| TBD Marketplace™
	Sell \| TBD Marketplace™

Florida Courts Technology StandardsSection VCourt Application Processing System