CCIS 3.0 High-level Data Transfer Design
Version: / 1.0Date: / 8/1/2015
Audience: / Stakeholder Technical Staff of IT Strategic Planning Committee
Author: / FCCC
Revision History
Version / Date / Author / Comments0.1 / 1/14/2015 / Jennifer Fishback / Document New Case Initiation in CCIS 3.0
0.2 / 1/21/2015 / Jennifer Fishback / Replace process diagram
0.3 / 1/28/2015 / Gary Axtell / Expand on Web Services
0.4 / 4/6/2015 / Jennifer Fishback / Add CCIS Audit web application details, CCIS 3.0 ICD modifications, Solution design considerations
0.5 / 4/14/2015 / Jennifer Fishback / Add web services security information and plan to phase all CCIS updates using web services.
0.6 / 4/24/2015 / Jennifer Fishback / Add schedule information. Add Delete functionality and Web Service Package design details.
0.7 / 5/1/2015 / Jennifer Fishback / Add cosmetic clarifications
1.0 / 5/14/2015 / Jennifer Fishback / Publish first non-draft version of documentation
1.1 / 8/1/2015 / Jennifer Fishback / Add Process Diagram Narrative section describing how web service documents and batch extract file processing are implemented
Add information regarding access security matrix implementation
Removed case delete language from web services
Purpose
The purpose of this document is to define the high-level technical solution intended for the 67 counties as custodians of the court record and FCCC as the owner of the Comprehensive Case Information System (CCIS) to describe, at a high level, the technical solution that will be implemented by all parties to meet the requirements of the users of CCIS 3.0.
CCIS Upgrade Overview
A phased approach will be taken to migrate from a nightly batch process to real-time web services to update the CCIS database. The first phase has been defined within this document with regards to technical solution and the timeframe and is being driven by the NCHIP grant.
Current Project Scope
CCIS 3.0 Phase 1 is scheduled to be completed by 3/31/2016.
Push Services
The Push services are named using “Receive” methods in the web services contract.
Add and Update
Provide real time CCIS database update when a case is added or updated at the local level so that CCIS users see the new case and party the same day they are added to the Clerk’s CMS. Tables in CCIS are updated for Case, Party, Party Representative, and Charge.
A package contains a snapshot of the party (or parties) that changed or was added. One party or multiple parties may be included in one package. If the party exists in CCIS, it will be replaced. If the party does not exist in CCIS, it will be added. If there is a party on the case in CCIS that is not included in the XML package, it will remain unchanged.
Delete
. Deletes will be handled in the batch process.
Pull Services
The Pull services are named using “Get” methods in the web services contract.
Display real time case data from the Clerk’s CMS for use by the CCIS Application users:
· Court event
· Financial Assessment
· Sentence
· Reopen history
· Judge assignment history
· Warrant/Summons/Capias
· Progress docket and images
Batch Process CCIS Database Updates
Refresh
The Data Refresh functionality will be used in two scenarios:
· Initial implementation of CCIS 3.0
· Major update to local CMS data
The batch process will be used to perform an initializing data refresh that must be performed prior to enabling the web services within county and application system ID.
The Refresh will also be used in the event that a significant number of cases is updated and exceeds the normal volume of CCIS updates. Examples:
· SQL run on local data that changes values on data elements that are stored in CCIS
· Judge reassignments
Incremental
When the push services are enabled, the CCIS Incremental Run for corresponding CCIS Files will exclude the county updates so that one single source is updating the CCIS database. If CCIS is updated using web services, the same updates should not be sent in the incremental batch run.
Future Migration from Batch to Web Services
As CCIS 3.0 is implemented, the team will work together to integrate more data in the push services to replace the incremental batch updates and the timeframe to complete the implementation. A CCIS User Group will define business requirements that will determine additional data needed in the CCIS Application or for reporting and/or BI.
Process Diagram
Process Diagram Narrative
Throughout the day, Clerk CMS generates push web service documents as case initiation and case updates and send them to the CCIS Message Queue.
Sometime in the evening, Clerk CMS generates batch extract files and place them on a FTP server in time to be available for the 7:00 PM CCIS Batch Processing window.
To integrate the two methods for CCIS updates, the message queue is temporarily stopped when the batch process begins. The messages continue to be received and held while the batch process runs. Once the batch process is complete, the message queue is turned on and documents are processed first in, first out.
Pull Web Services are initiated by the CCIS Application user to display Clerk CMS data on a specific case. The data that is returned to CCIS is not stored in the CCIS database for the initial CCIS 3.0 Implementation.
The Web Services Contract was designed to contain identical push and pull xml documents. Invoking them is the distinction being made on this project. Push xml documents are used to provide case initiation and case update CCIS database updates to be able to search for a case and party in CCIS. Pull xml documents are used to display Clerk CMS data to the CCIS user.
Online CCIS Web Application Upgrade
The application will be developed during the summer 2015 with a new user interface.
CCIS Application will display data from the following sources:
· CCIS database – Case, Party, Party Representation, Charge
· Clerks’ CMS – progress docket, images, sentence info, court events, financial detail, parcel information, etc.
· E-Filing Portal – E-service list email address (NEF)
· TCATS – traffic citation information
· CLERK – child support
The users will benefit from seeing detailed data regarding a case of interest that is contained in external databases. CCIS will take advantage of web services to make the data available to the users without duplicating data in the CCIS database that is not required to perform a case or party search or perform statewide reporting.
See Secured Access Provided section of the ICD for information on how the administrative order will be implemented in CCIS.
Web Services Details
Push Service
CCIS 3.0 will host a web service that will accept XML documents. This service will be SOAP based and will place the XML documents into a processing queue that will operate in a “First In, First Out” manner. A separate server process will then take the XML documents, process them, and add or update the data to the appropriate tables. This data will then be available for searching in CCIS 3.0.
· Each push will contain one document per message per service call.
· One message can be sent that contains multiple names for case.
· One message can be sent that contains multiple charges.
· One message can be sent that contains multiple causes of action.
Case Initiation
When a case is initiated, the Clerk CMS will send complete XML packages for the following:
Case / Description / PushCase Information / Basic information about a case / A case object
Case Party / A list of case parties including contact information and representation / A list of party objects
Case Party Representative / A list of the representatives for a party on a case / A list of party representative
Case Charge / A list of charges on a criminal case / A list of charge objects
Case Update
When the case (corresponding 110-02), party (corresponding 110-01), party representation (corresponding 110-08), or charge (corresponding 110-10) is updated in the CMS and would make a change to the data being stored in the CCIS database, the object specific to the changed data may be pushed. In other words, if party data is changed, the case and charges do not have to be pushed with it. However, all the data in the web service must be provided within that object since it will replace the whole party record in CCIS.
The CCIS 3.0 ICD used to define the batch extract process defines the data elements that are stored in CCIS. The Clerk CMS should push the xml documents only when there is a modification to the data element values in the CCIS database. This will minimize network traffic that is not necessary.
It is not necessary to push a ‘delete’ prior to pushing the update. The data will override the existing data in CCIS.
Pull Services
Dockets, Images, and other Critical Data
When a search is performed on a specific UCN in the CCIS Application, the dockets, images, and other critical data elements can be displayed using web services to access the information dynamically in real-time from the Clerk’s CMS for display to the CCIS user.
Docket Sheet
When a specific case is accessed in the CCIS Application, the application will make a call to the Docket web service that will provide a list of the docket sheet associated with the case. Along with each docket entry, if an image exists for that docket entry, an image identifier as well as other metadata will be provided.
Images
The image identifier mentioned under Docket Sheet will be used to first determine if an image exists for the docket entry. If so, the docket text in the CCIS 3.0 Application will be converted to a URL that links to the County’s image store. When a user clicks the link, a call will be made to the docket web service to return the specific image for that docket entry for viewing by the user.
Other Critical Data
For other critical data items such as warrants, sentence, financial, and court event data, a web service can be utilized to request the appropriate data package as specified in the CCIS 3.0 Data Exchange Standard. A specification will be provided as a companion to the CCIS 3.0 Data Exchange Standard to give County IT/CMS vendors the information they need to implement this service. These “data pull” web services will reside in the County and will be connected to the local CMS. The CCIS Application will support SOAP-based web services for these data pull operations. Should a County not implement the web service the data will be accessed from the CCIS database as updated in the nightly batch process. Also, if at any point network communications between FCCC and a County are disrupted, the CCIS database will be used to provide data until the communications have been restored.
Request Name / Description / Key / Returns /Case Assessment Request / A list of case assessments. The fee type code may have a CCIS code for types CCIS may need to report on. (Example: R for Restitution or AF for Attorney Fee) / Uniform Case Number / A list of assessment objects
Case Court Event Request / A list of court dates on a case. The event type code may have a CCIS code value that maps to a CCIS standard event code. / Uniform Case Number / A list of court event objects
Case Charge Sentence Request / The most recent sentence for the given case sequence / Uniform Case Number and Charge Sequence / A sentence object
Case Reopen History Request / A history of case reopens including types, dates, and close reasons. / Uniform Case Number / A list of reopen objects
Case Judge Assignment History Request / A history of judge assignments on a case. / Uniform Case Number / A list of judge assignment objects
Case Parcel Request / A list of parcels on a case / Uniform Case Number / A parcel object
Case Writ of Arrest Request / A list of warrants on a case / Uniform Case Number / A list of warrants/ summons / capias
CCIS Batch Process
The nightly batch process will continue to be used to perform the caseload refresh function. These must be scheduled for weekends. A full refresh will need to be performed for each county prior to enabling the web services push in order to populate the new database fields and to correct any known data issues. With 67 counties and 26 weekends during the implementation period to perform the refreshes, scheduling is critical. We must phase in the counties over the 6-month period in part due to the constraint of the length of time it takes to perform a refresh.
The batch process will continue to be scheduled as a nightly process Monday through Friday of each week (excluding Holidays) until web services are implemented statewide for all CCIS database updates.
The batch process will require data to be provided in logical data sets, as with the current CCIS 2.0 process, and will be expanded to include all new data requirements defined in the CCIS 3.0 ICD.
Overview of CCIS 3.0 ICD Updates
CCIS 3.0 File Definitions
Type / File / Description / Reason /Change / 110-01 Case Party / Add Address Country and Add Primary Party PIN / Capture out-of-country parties and relate all alternate party name records to the primary party name record
Change / 110-02 Case / Add AO14-19 Matrix field and case status code / To meet requirements for electronic access per the AO and to be able to report mortgage foreclosure case data to OSCA
Change / 110-05 Progress Docket / Add Docket Security flag, document page count and local docket sequence number / To conform electronic access per the AO, display document page count and to implement local docket numbering as discussed at FCTC
Change / 110-10 Charge / Add level and degree to each phase of a charge / Requested by CCIS users
Change / 110-20 Judge Map / Add judge type / Standardize judge type and encode the values
New / 110-16 Judge Assignment / Store all judges that have been assigned to a case / Requested by CCIS users
New / 110-17 Cause of Action / Store all causes of action on a civil case (filings) / Requested by CCIS users
Automated Reporting
Mortgage foreclosure report is provided to OSCA daily.