TBD | Section X - Florida Courts Technology Standards
Home About Contact |
Icon-UpArrow Handbooks → eFiling → FCTS → Section X
PDFLogo Download

Florida Courts Technology Standards
Section X


CAPSCourt Application Processing System
CMSCase Maintenance System
ECFElectronic Court Filing
FCTCFlorida Courts Technology Commission
JDMSJudicial Data Management Services
IEPDInformation Exchange Package Documentation
MDEMajor Design Element
NIEMNational Information Exchange Model
OASISOrganization for the Advancement of Structured Information Standards, a non-profit consortium for open standards
OCROptical Character Recognition
PDFPortable Document Format
PDF/APortable Document Format/Archival
SOAPSimple Object Access Protocol
TCPTransmission Control Protocol
XMLeXtensible Markup Language
W3CWorld Wide Web Consortium
WSDLWeb Services Description Language
WS-IWeb Services Interoperability Organization
Florida Courts Technology Commission (11/20)


[ECF Specification]Electronic Court Filing Version 4.01, https://www.oasis-open.org/standards/,
May 2013.
[FIPS 180-2]Secure Hash Standard, http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf,
National Institute for Standards and Technology,
August 2002.
[Genericode]A. B. Coates, Code List Representation (Genericode) 1.0, http://docs.oasisopen.org/codelist/ns/genericode/1.0/,
OASIS Committee Specification,
December 28, 2007
[NIEM]National Information Exchange Model 2.0, http://niem.gov,
[NIEM Guide]NIEM Implementation Guidelines, http://www.niem.gov/implementationguide.php,
[NIEM Techniques]Techniques for Building and Extending NIEM, http://www.niem.gov/topicIndex.php?topic=techPDF,
Georgia Tech Research Institute,
August 2007.
[Namespaces]T. Bray, Namespaces in XML, http://www.w3.org/TR/1999/REC-xml-names-19990114,
January 14, 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.
[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.
[RFC4122]Leach, et al., A Universally Unique IDentifier (UUID) URN Namespace, http://www.ietf.org/rfc/rfc4122.txt,
IETF RFC 4112,
July 2005.
[Schema Part 1]H. S. Thompson, D. Beech. M. Maloney, N. Mendelsohn, XML Schema Part 1: Structures Second Edition, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/,
W3C Recommendation,
October 28, 2004.
[Schema Part 2]P. Biron, A. Malhotra, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/,
W3C Recommendation,
October 28, 2004
[SOA-RM]MacKenzie, et al., Reference Model for Service Oriented Architecture 1.0, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm,
OASIS Public Review Draft 1.0,
February 10, 2006.
[UBL]Universal Business Language Version 2.1 30 May 2011. 30 May 2011. Committee Specification Draft 02 / Public Review Draft 02. http://docs.oasisopen.org/ubl/prd2-UBL-2.1/UBL-2.1.html J. Bozak, T. McGrath, G. K. Holman (editors), Universal Business Language 2.0,
OASIS Standard,
December 12, 2006.
[XML 1.0]T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), http://www.w3.org/TR/REC-xml/REC-XML-20040204,
W3C Recommendation,
February 4, 2004.
[XMLENC]D. Eastlake, J. Reagle, XML Encryption Syntax and Processing, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/,
W3C Recommendation,
December 2002
Florida Courts Technology Commission (11/20)


AnnotationA note that is added to a document by the creator. Annotations can be easily hidden and moved, possibly affecting the content of the document.
Asynchronous ResponseA message transmission returned at some time interval after the end of an operation, i.e., there is no immediate (synchronized) response between the communicating endpoints. Asynchronous transmissions use data flow parameters as opposed to synchronous transmissions that use a clock signal to keep the data flow synchronized. (See the terms Message and Message Transmission).
AttachmentInformation 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 standard. An attachment may be in XML format, non-XML text format, encoded binary format, or un-encoded binary format. (See the terms Message and Major Design Element (MDE)).
BookmarkA link connecting to a specific target in a document. Bookmarks usually indicate the document structure, but may also include sensitive words and phrases.
Callback MessageA message transmission returned by some operations sometime after the operation was invoked (asynchronously). (See the terms Message and Message Transmission).
Case Maintenance System (CMS)An electronic system used by the clerks of court to perform their court-related statutory duties, to include the major business functions outlined in the Consolidated Case Maintenance System Standards.
Case ManagementA systematic administration and allocation of resources, including judicial attention and leadership, time, court staff, court technology, and the resources or parties and communities, directed to enhancement of the quality, timeliness, and efficiency of the judicial system. Case management develops and maintains reasonable and achievable policies and practices, identifies, collects and organizes critical case information, responds appropriately to characteristics of cases and parties, organizes the movement of cases, ensures that necessary activities and events occur, marshals and prioritizes court and community resources, promotes reasonable and consistent expectations, provides critical information to judicial leaders and court managers, and promotes accountability and ongoing improvement (TCP&A, 2001).
Content ModelDescribes the information components used in the messages defined and how the information is organized. The data exchange content models will be the result of a detailed analysis of the data requirements to support the particular data exchange.
Core MessagesDefined by the core specifications which define the MDEs and the operations and messages that are exchanged between MDEs. These are required messages for the particular MDEs. (See the terms Message and Major Design Element (MDE)).
Court Application Processing System (CAPS)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.
Data ElementRequired information identified by rule, statute, forms, and any other pertinent information describing the activity of the court system either organizationally or in relation to activity within a specific court division.
Digital SignatureA specific type of electronic signature created using a mathematical algorithm (e.g., encrypted hash value) routinely used to validate the authenticity of a signer’s identity creating a virtual fingerprint that is unique to a person and the integrity that the message has not been altered.
DocketingThe process invoked when a court receives a pleading, order, or notice, with no errors in transmission or in the presentation of required content and records it as a part of the official record. (See the term Progress Docket).
Docket NumberAn alphanumeric number used by the clerks of court to identify a specific entry in a case docket.
Document IntelligenceInformation and metadata that is created during the lifecycle of a document. This includes viewable text, appearance, and hidden information such as document identifiers, tags such as those used to make the document ADA compliant, and other metadata.
Dots Per Inch (DPI)The measure of spatial printing, video or image scanner dot density, in particular the number of individual dots that can be placed in a line within the span of one (1) inch.
E-Filing Portal (Portal)The central electronic court filing facility that accepts court documents for filing in Florida courts, transmits them to the clerks of court, and can effectuate automated service via email upon all registered attorneys and parties associated with a case.
Electronic FilingThe automated transmission of legal documents from an attorney, party, or self-represented litigant to a court.
Electronic Filing EnvelopeData accompanying submitted documents which identify a submitted document, the filing party, and other sufficient information for entry in the court's docket or register of actions.
Electronic NotarizationA process whereby a notary affixes an electronic signature and notary seal using a secure public key to an electronic document.
Electronic SignatureA digitized signature that shows intent to sign a document. Acceptable electronic signature formats include “s/”, “/s”, or “/s/”.
EncryptionThe process of converting information or data into a form that is unintelligible to prevent unauthorized access.
Encryption KeyA random string of bits generated specifically to scramble and unscramble data to ensure that every key is unpredictable and unique.
ExhibitsDocumentary evidence.
File FormatA file representation of a document (e.g., Word, PDF, PDF/A).
FilerAny person who files a document into a court record, excluding the clerk of court or designee of the clerk, a judge, magistrate, hearing officer, or designee of a judge, magistrate, or hearing officer.
FlattenRemoving original document intelligence.
FrameworkA conceptual description of the components and other elements from which a working system can be built. A framework defines the boundaries of the system to be built and may constrain the operation of the components within. Depending on design considerations, the description of each component or element will vary in detail as necessary to clearly set boundaries and ensure the components work properly together.
HyperlinkAn icon, graphic, or text that points to a specific document or a specific element within a document.
Major Design Element (MDE)A logical grouping of operations representing a significant business process supported by the standard. 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. (See the terms Message and Synchronous Response).
MessageInformation transmitted between MDEs that consists of a well-formed XML document that is valid against one of the defined message structure XML schemas. A message may be related to one or more attachments in a manner defined in the standard. (See the term Attachment).
Message TransmissionThe sending of one or more messages and associated attachments to an MDE. (See the terms Attachment and Message). Each transmission must invoke or respond to an operation on the receiving MDE, as defined in the standard. (See Receiving MDE).
MetadataData that describes or gives information about other data. 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 business process. A sender invokes an operation on an MDE by transmitting a set of messages to that MDE, addressed to that operation. An operation will have an operation signature. (See the terms Message, Operation Signature, and Major Design Element (MDE)).
Operation SignatureA definition of the input message(s) and synchronous response message associated with an operation. Each message is given a name and a type by the operation. The type is defined by a single one of the message structures defined. (See the terms Message and Synchronous Response).
Optical Character Recognition (OCR)The electronic conversion of typed, hand-written, or printed text into a digital format using photoelectronic devices and computer software so the text can be edited or searched.
Progress DocketA list of each pleading, motion, or other paper and any steps taken by the clerk in connection with each action, appeal, or other proceedings before the court. (See the term Docketing).
Proposed OrderDraft of an order prepared by a party/parties for review and/or consideration by the court.
RasterizeConverting an image into pixels to print, display, or store the image in a bitmap file format.
Receiving MDEThe MDE that receives the request with the operation invocation performs the operation and sends the response. (See the terms Major Design Element (MDE) and Operation).
RedactionPermanently remove information from the document that is identifying or otherwise sensitive.
ScanningThe process of converting a paper document or picture into a digital copy using a device (e.g., scanner, phone, tablet) that has a camera or document scanner that uses chargecoupled or contact image technology. (See the terms OCR and DPI).
Searchable PDFA PDF that contains a bitmapped image of a document with textual content that can be searched.
Sending MDEThe MDE that sends the request including the operation invocation and receives the response with the results of the operation. (See the terms Major Design Element (MDE) and Operation).
Service Interaction ProfilesSpecifications that describe communication infrastructures that deliver messages between MDEs. (See the terms Message and Major Design Element (MDE)).
Service-Oriented ArchitectureA design pattern based on distinct pieces of software providing application functionality as services to other applications via a protocol. It is independent of any vendor, product, or technology. The W3C defines it as a set of components that can be invoked and whose interface descriptions can be published and discovered.
Synchronous ResponseA message transmission returned immediately (synchronously) as the result of an operation. Every operation has a synchronous response. (See the terms Message and Message Transmission).
Florida Courts Technology Commission (11/20)


Data exchange content models describe the information components used in all of the messages defined (See the term Message in Appendix C). The data exchange content models will be the result of a detailed analysis of the data requirements to support the particular data exchange. During the modeling process, common items of data will be identified by a process of normalization to identify aggregates based on functional dependency. Where appropriate, these will be generalized so that they can be re-used to support the various messages. The data exchange content models will be used for the following purposes:

• Facilitate the identification of the reusable components, i.e., the data structures that are common across the Data Exchange messages (See Appendix E).

• Aid in understanding the information requirements of the total scenario.

• The source from which the object classes are derived and documented in the Data Exchange XML Schemas (See the normative references for Schema Part 1 and Schema Part 2 in Appendix B).

To facilitate comprehension, several particular data exchange content model diagrams will be developed. Each diagram will represent a logical grouping of components and display both the attributes and object classes belonging to the components in the grouping. The scope of each diagram will be arbitrary and will not hold any significance beyond the diagrams. Florida Courts Technology Commission (11/20)


The key principles that shall guide the design of the Data Exchange message (see the term Message in Appendix C) structures are:

• Interoperability: The Data Exchange message structures shall provide a means for exchanging data among all types of court information systems.

• Completeness: The Data Exchange message structure format shall provide for all the elements for the particular data exchange.

• Simple implementation: The design should foster rapid implementation.

• Simple XML and portable structure: The core messages in a data exchange will be formatted as XML documents (See Appendix C).

• Familiarity: The data elements and code values shall be meaningful.

• Interdisciplinary utility: The design should be usable by a broad range of court-related applications.

Florida Courts Technology Commission (11/20)


This data exchange standard advances a common set of exchange capabilities that should be built upon to define a specific data exchange. The below general methods describe a minimal set of capabilities that each exchange must implement. However, implementation details are left to the individual exchange which need not define methods with these specific names. Refer to Figure 8. for a representative diagram.

Figure 8. Data Exchange MDE Reference

img-flowchart InitiateExchange

The Data Exchange MDE must allow for an external data source to initiate data exchange at any time. The initiation action for this method includes the direct transfer of data from the external data source to the Data Exchange MDE as part of the Initiate Exchange message. The Data Exchange MDE must respond synchronously with a message denoting receipt of the data or failure of the transfer. Failure messages must include a reason for failure if such a reason is identifiable by the Data Exchange MDE.


The Data Exchange MDE may request an exchange of data from another Data Exchange MDE. The receiving MDE must respond synchronously with the data requested, an error message, or by invoking the ScheduleExchangeRequest operation on the consuming Data Exchange MDE to schedule a date/time when the request will be filled. The RequestExchange message must include a unique identifier for the request that must be used through subsequent operations.


The Data Exchange MDE may satisfy a RequestExchange action by scheduling a date and time when the requested data will be provided. Messages must use the unique identifier established during the original RequestExchange operation.


The Data Exchange MDE must resolve a ScheduleExchangeRequest operation by providing the data originally requested by invoking the FillExhangeRequest operation on the requesting Data Exchange MDE. The FillExchangeRequest must use the unique identifier associated with the original RequestExchange operation. The message must contain the data requested. The Data Exchange MDE must respond synchronously with a message denoting receipt of data or failure of the transfer. Failure messages must include a reason for failure if such a reason is identifiable by the Data Exchange MDE.


The Data Exchange MDE must define a capability to establish arbitrary data exchanges. The complexity of court data exchange will necessitate specialized exchanges between local data providers. The OtherExchangeNotification operation should provide a mechanism for meeting this local exchange need through the appropriate message namespaces while remaining compliant with this specification.


A Local Data Exchange MDE may obtain the necessary exchange criteria parameters from a Data Exchange MDE by invoking the QueryExchangeCriteria operation. The invocation of the QueryExchangeCriteria must include a specific exchange UUID for which to receive criteria as the exchange of different data products may impose different limitations. The Data Exchange MDE returns a machine-readable WSDL describing specific limitations associated.

The following methods should not be exposed for general consumption. They are intended to provide management capabilities to local and/or internal data management systems authorized to interact with a specific instance of a Data Exchange MDE. In particular, the implementation details of the Local Data Management MDE is left to the specific jurisdiction. While it is expected that the accepted method of interaction with the Data Exchange MDE is via a web services protocol, the interaction between the Local Data Management MDE need not be constructed as a web service. This element of the diagram intends to illustrate the functionality that the Data Exchange MDE needs to define. For example, the Data Exchange MDE must have the functionality to enable a local, authorized data management system to initiate a request for data via the Data Exchange MDE. However, while the request for data may be accomplished via web services, the initiation could be accomplished by different means such as another web service, a locally defined message queue, or even a simple set of scheduled jobs.


The Local Data Management MDE may invoke this operation on the Data Exchange MDE to retrieve data from an external data provider. The Data Exchange MDE must respond synchronously reporting the date/time that the data was requested (via the RequestExchange operation) and the unique identifier for the request. The Data Exchange MDE must respond asynchronously with the requested data, the date/time the data is scheduled to be provided, or an error message indicating failure of the data transfer.


The Data Exchange MDE may invoke the GetExchangeAction on the local data management MDE if that system provides for it. The Local Data Management MDE must respond synchronously with a method, location, or mechanism to store or process the data received from the Data Exchange MDE.


The Data Exchange MDE must define a capability to exchange status and other relevant information with the Local Data Management MDE through appropriate messages and namespaces.

Florida Courts Technology Commission (11/20)

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

Please get the justice you deserve.


Icon-Email-WBIcon-Email-WG Icon-Youtube-WBIcon-Youtube-WG Icon-Share-WBIcon-Share-WG
Pages You Might Also Like