North Dakota State Court Administrator's Office
INFORMATION TECHNOLOGY SYSTEMS
INTEGRATION AND MIGRATION ANALYSIS
July 29, 1999
JUSTICE SERVED Project Team:
Christopher Crawford, Project Director
Susan Koenig, Senior Consultant
Larry Polansky, Senior Consultant
Phyllis Smith, Project Associate
David Lyons, Project Associate
3144 Broadway, Suite 4-500
Eureka, CA 95501-3838
Tel: 707-443-1900, FAX: 707-443-1906
TABLE OF CONTENTS
EXECUTIVE SUMMARY . . . . . . . 1
A. Introduction . . . . . . . 1
B. Background and Context . . . . . 1
C. Current Environment . . . . . . 2
D. Summary of Recommendations . . . . . 3
E. Recommended Projects . . . . . . 9
I. COURT APPLICATIONS . . . . . . 11
A. Introduction . . . . . . . 11
B. District Court Case Management Systems . . . 11
1. Functional Assessment and Comparison of UCIS and PCSS 11
2. Municipalities Using UCIS . . . . . 24
3. Integration of Case Management System Applications . 26
4. Electronic Filing . . . . . . 27
5. Document Imaging . . . . . . 28
6. District Court Case Management System Recommendations 30
C. Jury Management . . . . . . 36
1. Current Environment . . . . . 36
2. Recommendations . . . . . 37
D. Internet Applications (Mini-Data Warehouse) . . 38
1. Introduction . . . . . . . 38
2. What is a Data Warehouse? . . . . . 39
3. Uses of a Data Warehouse . . . . 40
4. Implementation Strategies . . . . . 41
5. Recommendations . . . . . . 41
II. EXTERNAL INTERFACES . . . . . . 43
A. Introduction . . . . . . . 43
B. Recommendations . . . . . . 43
1. Access to UCIS . . . . . . 43
2. Department of Transportation . . . . 45
3. State's Attorneys System . . . . . 46
4. Other Government Agencies . . . . 47
5. Private Attorneys . . . . . 49
III. ADMINISTRATION . . . . . . . 50
A. Office Productivity Recommendations . . . 50
B. Data Disaster Recovery Recommendations . . . 51
1. Hardware Availability and Reliability Issues . . 51
2. Data Disaster Recovery Plan . . . . . 52
3. Data Backup Procedures . . . . . 52
C. Training Recommendations . . . . . 53
D. Security . . . . . . . . 54
1. Data Security . . . . . . . 54
2. Computer Facilities Security . . . . 55
3. Password Security . . . . . . 56
E. Application Development Strategy . . . . 56
F. Project Management . . . . . . 57
G. Quality Assurance . . . . . . 60
H. Statewide Justice Coordination . . . . . 60
I. SCA Information Systems Staffing . . . 61
IV. MIGRATION, IMPLEMENTATION AND COSTS . . . 63
A. Recommended Projects . . . . . 63
B. Matrix of Projects with Cost and Effort Estimates . . 65
C. Administrative Recommendations Chapter III & Elsewhere 69
Appendix A . . . . . . . Glossary
Appendix B . . . . About JUSTICE SERVED
The North Dakota State Court Administrator contracted with Justice Served, a team of court management and technology consultants, for the purpose of analyzing Information Technology Systems Integration and Migration for the North Dakota Judiciary. Justice Served team members studied the Judiciary's information systems and court processes by reviewing information technology (IT) plans and user manuals, state court annual reports, recently-passed legislation, and other relevant documentation; and by interviewing dozens of IT users and policy-makers, both inside and peripherally to the courts. As a result of this intensive review, Justice Served presents recommendations for the future of IT in the North Dakota Judiciary. A summary of the key recommendations and resulting projects is contained in this executive summary. These recommendations and projects are explained more fully in the particular study area chapter of the report.
Information Technology is a powerful resource that must be closely tied to the organizational mission and strategy of the Judiciary. It must further these purposes and not serve as an impediment or activity that distracts court staff and judges from efficiently and effectively resolving court cases. System users should easily search for a particular case, match prior and companion cases, and generally access case-specific information concerning any filing at any location. Major agencies that interact with the court should have convenient access to relevant court records and, whenever possible, these agencies should have the capacity to file processes directly into the automated systems, receive notice and process directly from the systems. Finally, the public and attorneys should have the ability to inquire on general court information and case-specific information in a convenient, readily accessible manner.
The Justice Served project team makes its recommendations in this spirit. The project team has worked in courts as both consultants and court managers; each team member has seen a broad spectrum of IT applications, both good and bad. The recommendations contained in this report consider the purposes and performance measures of courts: to be accessible to the public; to be fair; to promote public trust and confidence; to be independent and accountable; to reduce unnecessary delay. Ultimately, court staff, processes and automation should further these aims.
B. Background and Context
The North Dakota Judiciary is an organization in transition. Major changes in the past 25 years include:
1959 The Legislature abolishes Justice of the Peace courts.
1976 Legislation amends the state constitution to create a multi-tiered state appellate and trial court structure.
1979 The Supreme Court organizes the District Courts into seven judicial districts encompassing multiple counties.
1983 Further legislation alters the structure of County Courts.
1995 The Legislature abolishes County Courts and expands the District Courts to absorb the workload.
1997 The Judicial Branch completes its 1997-99 Information Technology Plan, specifying goals and expectations for court automation in the near and far term.
1999 A legislative initiative moves toward state funding of County District Court Clerk's office operations in a phased-in strategy.
The end result is an evolution of the Judiciary that has grown from a series of semi-autonomous courts to a centralized network of judicial districts. Each change has posed a new challenge insofar as management structure, service delivery, uniformity of process and automation. The latest change will more fully complete the cycle of centralization.
IT must now provide a comprehensive network of functional data systems which share a common database and are accessible by the various users of court services, including the public. The operating platforms of these data systems must be powerful enough to run functional programs, and have sufficient capacity to store and retrieve a substantial amount of data. The programs themselves must be flexible enough to adapt to modifying procedures and legislative mandates.
C. Current Environment
There are five data systems currently supporting court operations in the Judiciary:
UCIS - Unified Court Information System - a software program that was originally purchased form Scot County, MN by the South Central Judicial District, and later acquired and enhanced by the State Court Administrator's Office to automate case processing in the District Courts. UCIS is operating at most District Court locations statewide except for low volume courts, and except for Cass County (Fargo) which operates PCSS. UCIS runs on a proprietary AS400 IBM platform.
PCSS is a county-purchased, vendor-developed (PCSS, Inc) software program that automates case processing only in the Cass County (Fargo) District Court. PCSS runs on a proprietary AS400 IBM platform.
SCDS - Supreme Court Docket System - the current software program developed by the State Court Administrator's Office to automate case processing in the Supreme Court. SCDS runs on a proprietary IBM System/36 platform, and is migrating to a client/server platform.
JUCIS - Juvenile Court Information System - a software program developed by the South Central Judicial District to automate case processing for juvenile delinquency and dependency operations. JUCIS runs on a proprietary IBM AS400 platform. The State Court Administrator has purchased a vendor-developed software program to replace JUCIS. It will operate on a client/server platform and will be made available to the District Courts.
Jury Management System - a software program developed by the State Court Administrator's Office to automate jury services in the District Courts. This system operates either on stand-alone desktop computers or on a computer network (client/server), and is in current use in 33 counties. Although there are no immediate plans to change this system, it will eventually need to be upgraded.
In addition to these case processing systems, there are several administrative systems supporting management functions in the State Court Administrator's Office, the Supreme Court and the District Courts. These systems support functions such as statistics, human resource management, payroll, and finance management.
A computer network consisting of nine network hubs is connected through a state backbone of fiber optics (1 hub), T1 data lines (3) and 56K modem lines (5). This network provides the connectivity of automated case management systems and administrative systems throughout the state as required. It is important to note that all of the county District Court locations are currently connected to the Judiciary network. This connection provides access to: Email; the statewide child support data system called FASCES (Fully Automated Child Support Enforcement System); and in approximately 50% of the counties, to UCIS. Current plans include expansion of access to UCIS to include more District Courts, but a substantial number will remain without an automated case management system.
D. Summary of Recommendations
Recommendations are fully described in each of the major Chapters of this report:
Chapter I. Court Applications
Chapter II. External Interfaces
Chapter III. Administration
It is important to note that recommendations contained in this report may not necessarily lead to projects. For instance, most of the recommendations in Chapters I (Court Applications) and II (External Interfaces) are aligned into prioritized projects, while none of the recommendations in Chapter III (Administration) are aligned into projects. The recommendations contained in this report are documented to provide guidance to the Judiciary in a wide range of matters relating to IT. Chapter IV (Migration, Implementation and Costs) describes the projects that result from recommendations. The projects are summarized in the following subsection of this Executive Summary entitled "Recommended Projects", and are described more fully in Chapter IV.
Recommendations are labeled with numbers that coincide with the Chapter in which they originate, e.g., I-1, I-2, II-1, II-2, and so forth. All of the recommendations contained in this report are summarized below:
CHAPTER I Court Applications
Recommendation I-1 The Supreme Court should promulgate a policy that all district courts are required to use the state-supported case management system selected by the Judiciary Technology Committee. (Phase 1)
Recommendation I-2 The Technology Committee should designate the Unified Case Information System (UCIS) as the single case management system that will be supported for the district courts statewide. Other CMS software in use throughout the state should be phased out. (Phase 1)
Recommendation I-3 Prior to Cass County converting to UCIS, the UCIS system should be modified and enhanced substantially. Cass County should participate in determining which changes to UCIS are necessary prior to conversion and in designing and testing the changes. (Phase 1)
Recommendation I-4 All district courts should operate UCIS from the SCA AS400 computer in Bismarck. (Phase 1)
Recommendation I-5 Develop a judge's module for UCIS using a Windows interface. Make this available to judges on the bench and in chambers. (Phase 2)
Recommendation I-6 During the 2003-2005 biennium, re-assess the future viability of UCIS. (Phase 3)
Recommendation I-7 In conjunction with planning for the new case management system and e-filing applications, conduct a detailed feasibility and cost/benefit analysis of electronic document management systems. (Phase 3)
Recommendation I-8 Plan to develop e-filing for selected case types after the next generation of case management system is implemented. (Phase 3)
Recommendation I-9 Before the current pool of potential jurors is exhausted in January 2001, the state should purchase an off-the-shelf jury management program. (Phase 2)
Recommendation I-10 The SCA should create a mini-data warehouse. Begin the process by identifying the users and their information requirements. This should cover a considerable range of users of both public and private data. With the paucity of data historically available, the user base and requirements can shift radically, so plan for an incremental build incorporating change and growth. Availability creates demand, so expect user requirements and the number of users to grow. (Phase 1)
CHAPTER II External Interfaces
Recommendation II-1 Provide inquiry-only access to UCIS to Corrections, Probation/Parole, State's Attorneys Offices, Bureau of Criminal Information, Highway Patrol, and other law enforcement agencies. (Phase 1)
Recommendation II-2 Provide public access to District Court data on the Internet. (Phase 2)
Recommendation II-3 Build a real-time interface to DOT's system to replace the download of the 526,000 driver license records each month. (Phase 1)
Recommendation II-4 Expand electronic transmission of traffic case disposition information from courts to DOT and standardize (or translate) disposition reporting codes to significantly reduce the rejection rates currently experienced by DOT.
Recommendation II-5 Investigate the possibility and/or practicality of electronic transmission of information regarding juvenile driving offenses and child support orders affecting the driver's license. (Phase 2)
Recommendation II-6 Identify the data elements and data format UCIS must receive from a prosecuting attorney's system to populate a criminal case record. (Phase 1)
Recommendation II-7 Provide useable electronic criminal case disposition information (including the arrest tracking number, or ATN) to BCI to improve the timeliness and completeness of criminal history information. (Phase 2)
Recommendation II-8 Build an electronic interface between UCIS and BCI to enter warrants and warrant rescissions into the BCI files to provide the most accurate and timely information. (Phase 2)
Recommendation II-9 Evaluate the practicality of providing electronic data sharing between courts and law enforcement for protective orders. (Phase 1)
Recommendation II-10 Encourage the electronic transmission of law enforcement case information to courts (traffic) and State's Attorneys (criminal cases). (Phase 3)
Recommendation II-11 Investigate the possibility of electronic transmission of requests for mental health evaluation and/or alternative treatment as well as for reports from the mental health service to the court. (Phase 3)
Recommendation II-12 The Bar Board should frequently provide a complete and up-to-date attorney file to the Central UCIS. (Phase 1)
Recommendation II-13 Modify the court rule to require attorneys (not the 15-20% of pro-se filers) to file the electronic copy of their brief in a current version of Word or WordPerfect only. (Phase 2)
CHAPTER III Administration
Recommendation III-1 As much as possible, the North Dakota judiciary should decide on a single office productivity software program. This will allow different offices to share documents easily, and will also allow the judiciary to more easily install other software, such as a case management or jury program, that interfaces with a word processing program. (Phase 1)
Recommendation III-2 Procure a redundant power supply for the AS 400 server when a product becomes available for this model. Backup power sources, whether they be uninterruptible power supplies (UPS) or power generators, should be tested every six months to insure that they work when they are needed. (Phase 1)
Recommendation III-3 Develop a data disaster recovery plan for information resources under the direct control of the North Dakota State Court Administrator's Office. Consider backing up to the State's mainframe using their ADSM product. Examine fire suppression options (including the use of Halon) for the room where state servers operate. (Phase 2)
Recommendation III-4 Verify the last full backup of the court-operated AS400 once a month and test the backup system every three months. Test the Supreme Court backup system every three months. Verify that backup systems at other sites are tested every three months. Consider backing up the AS400 and the Supreme Court system to the State's mainframe using their ADSM backup product. Provide a fireproof, waterproof, anti-magnetic lockable storage case at all locations storing backups. Require that the backup be stored in an occupied residence because of the potential damage that may occur to a backup tape left in a vehicle in extreme heat or cold. (Phase 1)
Recommendation III-5 Create a full-time position with a court user background to serve as a training director. This position should also provide user analyst services to the current IT staff. The training director should develop court-specific systems training materials, including self-paced, self-directed training software available on the Judiciary network and CD-ROM. (Phase 1)
Recommendation III-6 Purchase professional training and commercial training materials for common software such as word processing, web browsers and spreadsheets, to conserve in-house training staff resources for court-specific systems training needs. (Phase 1)
Recommendation III-7 Designate a security administrator in the SCA's office to review security issues, investigate security threats and maintain current knowledge of security issues including password administration, network security issues, viruses, data facilities security and other issues related to data security. Develop a statewide security plan for all data and computer resources controlled by the Judiciary. Ongoing, periodic security training for all courts personnel should be developed or purchased, including self-directed, self-paced training software available on the Judiciary network and on CD-ROM. (Phase 1)
Recommendation III-8 The security administrator should establish written agreements with all district and other facilities not under the court's direct control who provide computer services to the courts or who have access to the court's data to maintain agreed-upon levels of security. These contracts should specify the required level of security necessary for the courts. All private contractors working with the courts who provide data hardware or software services should be required to provide a written agreement to abide by security policies and procedures established by the North Dakota State Court Administrator's Office. (Phase 1)
Recommendation III-9 The Security Administrator should develop procedures to review passwords for all systems to insure that they meet court guidelines. (Phase 1)
Recommendation III-10 Adopt a procurement model similar to the Canadian model for managing all outsourced IT projects and utilize appropriate aspects of the model for in-house projects. Pay particular attention to negotiating contracts and implementing "gating" and "off-ramping" procedures. Implement change management techniques to insure successful IT project implementation. (Phase 1)
Recommendation III-11 As a Quality Assurance measure, IT staff should address the projects recommended in this report within the context of the next three biennium budget cycles, as Phase 1, Phase 2 and Phase 3 priorities. Using the "gating" and "off-ramping" provisions described in Section III.F., Project Management, the progress of each project should be examined to determine that it is on track, if adjustments are required, or if a project should be cancelled. A natural milestone for this exercise is the Biennium examination of the Judiciary's IT Strategic Plan, which occurs in January of each even numbered year. (Phase 1)
Recommendation III-12 The Judiciary should assume a leadership role and initiate a statewide justice coordination effort to provide a forum for justice-related agencies to explore IT system acquisition and development that is compatible and, whenever possible, integrated. (Phase 1)
Recommendation III-13 Increase the number of SCA IT staff to recognize the increased responsibilities of Information Technology management, with a priority to add a position with a court user background for training and user analyst services. Add at least one contract programmer due to UCIS interfaces and modifications. (Phase 1)
E. Recommended Projects
Recommendations summarized above may not necessarily lead to projects. Only the major recommendations in Chapters I (Court Applications) and II (External Interface) are aligned into projects which are described more fully in Chapter IV (Migration, Implementation and Costs). The remaining recommendations and all of the recommendations contained in Chapter III (Administration) are not aligned into projects, because they address administrative, strategic, project management, security and training aspects of IT management. Some of these administrative recommendations will have cost implications, which are noted in the their respective chapter.
The projects are summarized below:
PHASE 1 PRIORITY PROJECTS
(to be completed in the first Biennium, 1999-2001)
PROJECT #1 UCIS Modifications
Resulting from Recommendation numbers I-1, I-2 and I-3
Description: Improve the functionality of the UCIS District Court case management system for current and future users.
PROJECT #2 Upgrade the SCA operated AS400
Resulting from Recommendation number I-4
Description: Upgrade the SCA operated AS400 to enable the migration of Grand Forks and Cass Counties, as well as future District Court and ancillary agency users.
PROJECT #3 Migrate Grand Forks to the SCA Operated AS400
Resulting from Recommendation number I-4
Description: Move UCIS case processing from the county operated AS400 in Grand Forks to the SCA operated AS400.
PROJECT #4 Public Access to UCIS Case Information
Resulting from Recommendation number I-10
Description: Create a "mini data warehouse" to contain limited current and past case information, primarily for the purpose of public and attorney access via the Judiciary Internet site.
PROJECT #5 Two-way, Real Time Updating of DOT Records
Resulting from Recommendation numbers II-3, II-4, and II-5
Description: Create a link with the Department of Transportation for the purpose of receiving up-to-date drivers license information, and to report traffic-related violations.
PROJECT #6 Bar Board Attorney Information Updates
Resulting from Recommendation number II-12
Description: Create a link with the Bar Board to provide up-to-date attorney information to users of UCIS.
PHASE 2 PRIORITY PROJECTS
(to be completed in the second Biennium, 2001-2003)
PROJECT #7 Migrate Cass County to the SCA Operated AS400
Resulting from Recommendation number I-1
Description: Move case processing from the county operated AS400 in Cass County to the SCA operated AS400. If it is possible to accelerate this project into Phase 1, every effort should be made to do so.
PROJECT #8 Develop UCIS Judge's Module
Resulting from Recommendation number I-5
Description: Develop a specialized module in UCIS with a Windows interface for use by judicial officers.
PROJECT #9 Acquire Jury Management System
Resulting from Recommendation number I-9
Description: Replace the current jury management system with vendor software.
PROJECT #10 Create UCIS Link with BCI
Resulting from Recommendation numbers II-8 and II-9
Description: Provide a direct link to the Bureau of Criminal Information for the purpose of updating criminal warrant and conviction information.
PHASE 3 PRIORITY PROJECTS
(to be completed in the third Biennium, 2003-2005)
PROJECT #11 Re-assess Future of UCIS, E-filing and Imaging
Resulting from Recommendation numbers I-6, I-7 and I-8
Description: Conduct an assessment of the cost and functionality of vendor developed case management software before embarking on expanded development of UCIS.
This chapter discusses several types of applications and technology for the district court. The most important application for any court is its case management system (CMS). This chapter first reviews and compares the functionality of the two major case management systems in use in North Dakota and then discusses whether interfaces are justified between the three case management systems serving the Supreme Court, the District Court and the Juvenile Court. The impact of municipal courts on UCIS is also analyzed. These analyses are the basis for our recommendations concerning the future of district court case management systems statewide.(1)
Electronic filing and document management systems are applications that garner a great deal of attention in court circles because of the massive amounts of paper flowing through courts. Moving paper can be frustrating and slow, and naturally the question quickly arises how can we use technology? This chapter takes a look at e-filing and document imaging and provides an analysis of the circumstances under which they are most beneficial and cost-effective, and where they are not justified. A recommendation is made for further study and a pilot project.
The chapter concludes with an assessment of and recommendations concerning the jury management system.
B. District Court Case Management Systems
1. Functional Assessment and Comparison of UCIS and PCSS
North Dakota district courts use two case management systems. The Unified Case Information System (UCIS) is a statewide CMS that originated in Scot County, Minnesota and was imported into North Dakota first by Burleigh County. The software was acquired by the State Court Administrator's Office from Burleigh County in the early 1990s. The system has been substantially enhanced over the intervening years and is now installed in 24 counties and all but one district. An interface between the State's Attorney Management System (SAMS) and UCIS passes data between the systems, but its use is currently limited to one county (Grand Forks) where UCIS and SAMS reside on the same AS400. UCIS code is owned by the judiciary and no license fees or yearly maintenance fees are required for the software.
Cass County embarked on automating case management via purchase in 1991 of a vendor-supplied product called PCSS. PCSS, too, has undergone some modifications by the vendor, and the county information systems department has developed add-on programs that work with PCSS data files to produce customized reporting for Cass County. Court staff have taken advantage of the customization capabilities of PCSS to tailor it to the court's needs. In addition, the jail and the State's Attorney's Office are (or plan) using PCSS applications, and together with the court, data is passed between applications in an integrated criminal justice system. Cass County is the only county in the East Central Judicial District that uses PCSS. The other counties are not automated and are quite small.
Under state legislation passed this spring, most clerks of district court and their staff will become state judicial system employees, and all clerk's offices will be required to operate in a manner consistent with state standards, procedures and guidelines. Automation and technology for these offices will become the responsibility of the judicial branch.(2) The best information available to the project team is that Cass County will elect to turn over the operation and funding responsibility for the district court clerk's office to the state judiciary. Therefore, the question will soon arise as to whether Cass County should be permitted to retain its PCSS system when the clerk of district court becomes a state judicial system office.
In addition to the question about PCSS's future, the question has been posed as to whether UCIS is an application that the North Dakota judiciary should count on as a long-term solution or as an interim solution until a replacement system can be put in place. Should UCIS be replaced? If so, how by acquisition of a vendor-supplied system, rewrite of the existing system, acquisition of another public domain transfer program, or some other method?
This section of the plan provides an analysis and comparison of the two applications, and makes recommendations concerning a statewide policy on CMS applications. Recommendations for the future of a statewide CMS are provided in section I.B.6 and a migration plan is outlined in Chapter IV. In our review of UCIS, we did not observe system sluggishness, or other symptoms that would indicate the need for an analysis of the database structure. In our opinion, the soundness of the UCIS database is sufficient to meet the needs of the Judiciary for the near and intermediate term.
In order to determine whether either PCSS or UCIS provides the required functionality of a good case management system(3), a detailed analysis was performed on-site in the courts. Court staff answered a structured questionnaire about the applications and demonstrated the manner in which they use the systems for all case types. Sample reports and inquiries were run. The two systems were compared head-to-head on numerous detailed functions in 14 major categories. For each of these categories, a table comparing the two systems is provided below, together with a brief discussion of the strengths and weaknesses of each system. The tables have been developed from evaluations of numerous court case management systems used in more than a dozen states. Functions that do not apply to North Dakota have been eliminated from the matrices and other functions have been modified to fit procedures in the state.
It is important to note that this evaluation was structured to make a comparison of the two systems as objective as possible. Subjective judgment is unavoidable, but it is offered from the perspective of seasoned court managers who have seen several automated case management systems, both good and bad. The comparison, therefore, reflects our best judgment of what functionality exists based upon first- hand observation, to what degree that functionality actually performs, and the desirability of certain functions. It is the SCA, IT staff and the users who must ultimately decide what functionality is most needed in the particular operating environment of North Dakota. It is our intent to offer this analysis as a starting point for these considerations.
"Y" = Yes, the function is included
"N" = No, the function is not included
"P" = Partially included
"?" = Function not demonstrated
Basic Case Information and Case Initiation
|Maintain basic case identifying information such as case title, filing date, initiating document, case type and statistical category, initiating filing agency, court location, arresting agency, etc.||Y||Y|
|Download basic case identifying information from another system at the time of case initiation.||P||P|
|System assigns next sequential case number within case type or category; permit manual override.||YN||YN|
|Easy navigation through case initiation screens.||N||Y|
|Maintain numerical cross-reference numbers (e.g., other agencies' case numbers, jail booking number, etc.).||Y||Y|
|Appropriate vehicle-related identifiers for traffic cases (e.g., make, model, plate number and state, etc.).||Y||Y|
|Maintain case status (active, disposed, outstanding warrant, etc.) sufficient for operational and statistical purposes.||Y||Y|
|Status of jury demand and size of jury.||Y||Y|
|Establishes links between the case record and participant records, court appearances, docket or register of actions entries, financial transactions, sentences, judgments, sentences and other case information.||Y||Y|
|Permit re-opening of a case.||Y||Y|
|Generate case title from plaintiff and defendant names.||Y||Y|
|Void and re-use case number with password protection.||N||Y|
|Create logical link between related/coordinated cases and prompt user for update of both cases.||N||N|
|Create logical link between consolidated cases .||N||N|
|Update both related/coordinated cases simultaneously with identical information .||N||N|
|Transfer or copy information on case when transferred in from another county.||N||N|
|Create and print file label.||N||Y|
This category encompasses the data and functions necessary to open a case on the system, establish links between related cases and maintain basic information at the case level. The type of information maintained in each system is very similar. Both systems have the same weaknesses concerning related or coordinated cases, which cannot be linked in either system. This means that the clerks and judges must know which cases are scheduled for joint hearings, which cases a defendant is being sentenced on, etc. without assistance from the software.
There are three major differences between PCSS and UCIS in this functional area. First, both systems have some capability to download case initiation information from an external system, but neither system has the exact capability of the other. For criminal cases, PCSS downloads case information (including defendant and charges) from the State's Attorney's PCSS system without re-keying the information. For traffic cases, UCIS copies a considerable amount of information from the DOT download file to create the case. Second, PCSS presents the user with a series of screens, effectively leading the user through the case initiation process. UCIS makes the user select each function from a menu, which is more cumbersome and less direct. Third, PCSS creates file labels whereas UCIS does not have this capability.
|Maintain identifying information (name, address, SS#, etc.) appropriate to the role of the participant. Defendants in traffic and criminal matters have more extensive personal information than civil litigants.||Y||Y|
|Personal, identifying information sufficient for generation of a warrant.||Y||Y|
|Identify each participant's role in the case. Allow multiple roles..||Y||Y|
|Pro se designation.||Y||Y|
|Maintain attorney table with attorney name, address, firm, affiliation, type of attorney, bar number, standing, fax, e-mail and phone, and other information as needed.||P||P|
|Establish and update links between attorneys and parties. Maintain beginning and ending date of representation and attorney history.||P||P|
|Record the status of participants in a case and date of status (e.g., active, dismissed, judgment debtor, etc.).||N||Y|
|Link aliases and business name to a case party.||Y||Y|
|Minimize data entry through use of codes for participants and identifiers for regular justice system participants (e.g., prosecutors, attorney bar numbers, etc.).||Y||Y|
|Specify which participants should receive notices.||N||Y|
|Automatic updating of criminal defendant custody status.||N||N|
|Link new cases to a criminal defendant.||N||N|
|Interpreter required and language.||N||N|
|Import attorney information from bar association.||N||N|
|Maintain attorney status, prevent filing by disqualified or suspended attorney.||N||N|
This area included all functions necessary to maintain information about any party to a case, attorneys, and other case-related persons (i.e., non-litigants such as police officers, probation officers, foster parents, victims, etc.). The systems are very similar in terms of data and functionality, with a few exceptions. Both systems are reasonably good and have most of the basic capabilities needed in a CMS, with a few minor exceptions.
PCSS enables a clerk to select the parties or attorneys to receive notices, which is preferable to UCIS, which prints notices for all. Both systems use numbers to identify attorneys, but the use of the state bar number is preferable because it is consistent throughout the state. PCSS uses a number that is locally assigned by the Clerk's Office. Neither system has the capability to import attorney information from the bar association's automated system. Neither PCSS nor UCIS tracks the status of an attorney in the case (except through an entry in the register of actions when an attorney withdraws from the case) nor does either system prevent an attorney who is disbarred or suspended from filing documents or appearing in a case. Although this does not happen often, a good system should have this safeguard.
Adult Criminal Charges, Sentences and Warrants
|User defined charge table with code section and title.||Y||Y|
|Assigns count numbers.||Y||Y|
|Maintain/amend charges, charge status and disposition of each charge (e.g., plea, verdict, amended, dismissed, etc.).||Y||Y|
|Traffic fees (bail schedule) maintained in table.||Y||Y|
|Create sentence on individual charges.||Y||Y|
|Minimize data entry through coded entries, where practical.||Y||Y|
|Maintain all types and combinations of components of the sentence (e.g., restitution, jail, prison, suspended, probation, fine, community services, etc.).||Y||Y|
|Maintain accurately concurrent and consecutive sentences.||Y||Y|
|Maintain bail amount.||Y||Y|
|Grant extension of time to pay, perform sentence, etc..||Y||Y|
|Produce various types of bench warrants from data in system.||Y||Y|
|Print individual/batch warrants/batch.||P||Y|
|Remove/restore case to court's control based on warrant status.||Y||Y|
|Produce judgement/sentence forms (misdemeanor).||Y||N|
|Produce sentence/commitment forms (felony).||N||N|
|Amend sentence without overwriting original sentence.||N||N|
PCSS and UCIS are quite similar in their capabilities and functions with respect to updating criminal cases. The major difference is that UCIS has a check-off-the-box screen, which is used to create a misdemeanor sentence and judgment form, while PCSS does not. Each court is accustomed to their own procedures, but the consultants believe the UCIS screen is more functional and could be used for data entry in the courtroom, as it is in Grand Forks. Neither system handles amended sentences well. A good system should maintain the original sentence, while accepting the amended sentence or the revocation of probation and re-imposition of original sentence. Both systems have a full line of bench warrants that can be printed in batch or individually.
Judge Assignment, Scheduling, Calendaring and Notices
|Maintain judge table.||Y||Y|
|Automatic, random assignment of judges to cases.||Y||Y|
|Balance judicial caseload.||Y||Y|
|Block assignment of a judge to new cases until a future date.||N||N|
|Easy mass re-assignment of cases to another judge.||N||N|
|Easy re-assignment of calendar to another judge.||N||N|
|Maintain history of judges recused or disqualified on a case.||N||N|
|Maintain history of hearing judges.||Y||N|
|Maintain individual calendar schedule for each judge.||Y||Y|
|Maintain master calendar schedule for court sessions.||Y||Y|
|Maintain personal judge appointments, merge with judicial calendar, display of personal appointments is password protected.||P||N|
|Maintain calendar of court holidays and weekends; warn of scheduling at inappropriate times (e.g., holiday or 1am), but allow override.||P||Y|
|Allow setting of any hearing type for any calendar.||Y||N|
|Permit user to restrict hearing types for a calendar session.||N||Y|
|Set limit of number of cases to be heard at a calendar session.;||Y||Y|
|Allow over-scheduling, after warning.||Y||Y|
|Allow case to be set for multiple purposes on one calendar.||Y||Y|
|Allow multiple cases to have same start time on a calendar (e.g., 8:30 am Master Calendar).||Y||Y|
|Optional automatic scheduling.||Y||Y|
|Conflict checking for attorneys if automatic scheduling is used.||Y||N|
|Prompt user to schedule all related, consolidated or coordinated cases.||N||N|
|Automatically vacate future hearing dates when case is closed.||Y||N|
|Easy scheduling of hearing/trial over multiple days of weeks.||Y||Y|
|View or print judge's calendar for day, week, month. Detailed and overview calendars should be available.||P||P|
|On-line judge's calendar suitable for viewing on the bench.||N||N|
|Extremely flexible user-defined printed calendar formats user placement of data on page, selection of information, number of cases per page, line separation, etc..||P||P|
|Append freeform notes to judge's calendar.||N||N|
|Prevent additions to calendar (flag calendar as final); update with password.||N||N|
|Batch/individual print of calendar.||P||P|
|Export calendar to word processing package for further editing.||N||N|
|User-defined sort order for cases (multiple sort orders and layered sort orders can be defined).||P||P|
|Related cases kept together on calendar.||N||N|
|User-defined notice formats.||N||Y|
|Optional export of notice to word processing document.||N||N|
|Automatic docketing of notice.||N||Y|
|Production of proof of mailing.||?||?|
|Individual and batch notice printing options.||P||P|
|Maintain a history of court appearances for a case.||Y||Y|
|Record outcome of court appearances.||P||P|
|Display/retrieve previous or scheduled appearances by appropriate user-defined parameters.||Y||Y|
|On-line access by criminal justice agencies to court's calendar (through BBS, e-mail, access to the court's system, download or Internet, etc.).||Y||Y|
Burleigh and Cass Counties, where the systems were reviewed, operate on an individual calendar (except for the master calendar for pretrial criminal hearings). This functional area is perhaps the most divergent between the two systems, especially with respect to setting up court calendars and scheduling cases. To some degree the way PCSS operates in Fargo is reflective of the calendaring practices of that court, which has a more rigid schedule than many smaller courts. The rigid nature of the PCSS scheduling system is an asset for this court rather than a detriment, as it would be for other courts. PCSS requires that only one type of hearing can be set for any calendar session (a set time frame)(4). In UCIS, any type of hearing can be set for any time frame. PCSS requires a great deal of set-up to establish court sessions for the entire year (this is done on a six-month or quarterly basis in Fargo). The automatic scheduling system is dependent upon a schedule being set up for each day so that it can find an appropriate slot. Both systems can establish a maximum number of cases for a calendar time period and can warn or prohibit over-scheduling. One weakness of both systems is the lack of warning of scheduling at inappropriate times, such as 1:00 am, when doing manual scheduling. Both systems allow holidays and non-judicial days to be blocked out.
The automatic scheduling of each system operates somewhat differently. UCIS is reportedly capable of taking into account attorney's schedules to avoid scheduling conflicts, while PCSS is not. The PCSS automatic scheduling is more suited to criminal and small claims cases than larger civil matters. Because the project team did not observe the UCIS automatic scheduling function working properly, or the users were not familiar with its use, it was not clear how it compares with PCSS.
The printed calendar formats available from each system seem quite limited by comparison with other case management systems. Most of the better systems have the ability to sort cases on the calendar in different ways, put cases in a specific order and keep related cases together on the calendar. More information would be desirable on some calendars (e.g., charges on criminal calendars; moving party on motions hearings). Freeform calendar notes and a brief case history are often useful for judges. The calendars that are currently produced are satisfactory for public calendars to be posted in the hallway. On-screen calendars are better in UCIS than PCSS, but neither system is completely adequate in this respect.
One particular problem with UCIS is that it does not support notice formats tailored to a specific court location. All notices are pre-programmed and are consistent for all courts using the system. UCIS notices are also unsatisfactory with respect to aesthetics all text is in capital letters and formatting is rudimentary. Neither system allows the user to export the notices to a word processor for formatting. It is our understanding that a software interface named "EZPrint" has since addressed this problem in UCIS. Notices can be tailored more easily in PCSS. Notice templates are created in a word processor (AS400 Office Vision) and presumably separate notices could be created for each court using the system. Notices can also be generated automatically when an event is scheduled, whereas this is not the case in UCIS. Notices are automatically docketed in PCSS, but not in UCIS.
Case History (Documents, Actions, Financial Transactions and Events)
|Entries include: events, documents, financial transactions, notes, links to clerk's minutes.||Y||Y|
|Data includes: action/filing date, standard description , variable/inserts and/or freeform text, event type, date, department and time of scheduled hearing, dollar amount (financial transaction), clerk's initials, filing party and other required data.||P||P|
|User-defined mnemonic codes.||N||Y|
|Default to today's date, but allows override, for data entry.||Y||Y|
|Default to clerk's initials based on user ID.||N||N|
|Future scheduled hearing appears immediately in register of actions.||Y||Y|
|Print individual case register of actions.||Y||Y|
|Display register of actions based on activity or docket code actions (e.g., display only financial transactions for a case).||N||Y|
|Mass docketing (one event for multiple cases, all info the same).||N||N|
|Print/view register of actions in chronological or reverse chronological order.||Y||Y|
This set of functions refers to the creation of the case history, including filing of documents and the record of any events or actions on the case. Both systems have similar capabilities, with one major exception PCSS users make docket entries using mnemonic codes, which saves considerable time. The resulting entry employs standard language and may be edited to add explanatory detail. UCIS entries are entirely freeform, which takes longer and leaves more chance for error and non-standard language. The PCSS method is preferable. However, both systems lack certain information that should be in a docket entry: the clerk's initials, the party filing the document, and the event/document/action type code. Neither system has a facility for mass docketing (one action applied to multiple cases), which might be useful for the larger courts. The printed case history or register of actions did not appear well formatted in either system the information was difficult to find and read.
Courtroom Minutes and Forms
|Create detailed minutes (smooth minutes); merge case data with text.||N||N|
|Create check-off-the-box minute forms; merge case data with form.||Y||N|
|Link minutes with register of actions entry for viewing.||N||Y|
|Update hearing outcome/ results, judge, attendees, documents filed, etc.||Y||Y|
|Update sentences, charges, dispositions, etc. easily in court.||?||?|
|Schedule new appearance easily.||N||N|
|Practical for courtroom use.||?||?|
PCSS is not used in the courtroom, and UCIS is used in the courtroom only in Grand Forks. The systems are updated after court, but there are no courtroom minute orders produced as is the practice in many other states. Therefor, the lack of functionality in creation and linking of minutes to the register of actions is not of concern. Further analysis and experimentation would have to be performed to assess whether any enhancements would be needed to make either system courtroom-ready.
|Create and maintain ticklers for future events linked to a case.||Y||Y|
|Retrieve and view ticklers by various parameters: case number, due date, clerk, case type, event, etc. as appropriate (user-defined).||P||P|
|Track completion of events remove tickler automatically when event or register of actions entry satisfies requirement.||N||N|
|Issue notice/other user-defined output if deadline not met.||Y||N|
Both PCSS and UCIS have a tickler function, and they appear to be roughly equivalent in sophistication, with two exceptions. UCIS can perform an action, such as generating notices, based on a tickler. PCSS seems to have the better retrieval capability, although ticklers can be retrieved on only a very limited number of key fields in both systems. Neither system can remove a case from the tickler list if a certain activity occurs and is recorded in the system (e.g., a document is filed or a payment is made).
Indexing and Inquiries
|Name search on last name only, full name, partial name (first few characters), phonetic (Soundex) or wild card.||P||P|
|Case inquiry on party name, party type, case number, filing date, case status, judge assigned, cause of action, case type and other common elements.||P||P|
|Inquiry may be modified by a date range, case type or other parameter.||N||Y|
|Output to microfilm.||N||N|
|Civil/small claims judgment index.||Y||Y|
|Criminal defendant index.||Y||Y|
This category refers to the ways in which case information can be retrieved on screen and in printed form. The inquiry capabilities of the PCSS system appear to be marginally better than UCIS because there are more ways to limit searches. However, the name search function seems to be almost equivalent, and is satisfactory in both systems. UCIS has an on-line civil judgment index, while PCSS does not.
File Tracking and Management
|Check out/check in case file.||N||Y|
|Indicate due date for return (optional).||N||N|
|Display file location.||N||Y|
|Save last 5 transactions per file.||N||N|
|Establish user-defined file and document retention schedule.||N||N|
|Display/print several indexes for files: by borrower, by date due, by case number, by overdue files, etc.||N||N|
|Uses bar codes for attorneys (bar number) and files (case number).||N||N|
|Display/print last 5 locations for file.||N||N|
|Display/print file/document destruction list.||N||N|
PCSS has minimal file tracking and management capability, but Cass County reportedly does not use it. The clerk's office puts an outcard in the file location when a case file is circulating. Conversely, UCIS does not have a file tracking function, but at least some clerk's office staff want this function to be added. Whichever way a court chooses to implement file management on an automated system or manually they should be consistent about the method in order to be successful. Automating file management has some additional advantages when it comes to file and document retention schedules that are harder to implement in a manual system. The functionality of a file management system should have more capabilities of the sort listed above to be useful.
|Maintain log of exhibits for each case.||N||N|
|Maintain exhibits return and destruction schedules.||N||N|
|Display/print reports of cases and exhibits for return or destruction.||N||N|
|Print return letters.||N||N|
Neither UCIS nor PCSS has an exhibits management component.
|Cashiering is integrated with and accessible from case management screens.||Y||Y|
|Calculate and assess filing fees, copying and other miscellaneous fees based on filing code.||N||Y|
|Track fee waivers.||N||Y|
|Track fines, bail, court costs, and other financial assessments.||Y||Y|
|Record cash receipts.||Y||Y|
|Receipts: print, void, multiple copies, auto numbering, security.||Y||Y|
|Accept multiple payment types for one transaction.||N||Y|
|Split and credit one payment among more than one case.||N||Y|
|Accept credit card payments.||N||N|
|Perform automatic funds distribution to multiple funds based on user-defined allocation tables.||Y||Y|
|Cash drawer balancing and reports.||P||P|
|User-defined accounts; full general ledger.||N||N|
|Post financial transactions to accounts and subsidiary ledgers and journals.||N||N|
|Maintain audit trail with user ID.||N||N|
|Track and reverse NSF checks.||Y||Y|
|Prepare bank deposit forms.||N||N|
|Process miscellaneous cash receipts (non-case related).||Y||Y|
|Maintain bond ledger.||Y||N|
|Maintain trust accounts.||Y||Y|
|Maintain accounts receivables (fines, restitution, etc.).||Y||Y|
|Print financial notices reminder letters, account summaries, statements, overdue notices, etc.||Y||Y|
|Calculate payment schedules.||N||N|
|Appropriate indexes and inquiries.||Y||Y|
|Full range of accounting reports.||Y||Y|
Both PCSS and UCIS have good financial functionality, with a few exceptions. PCSS does not keep track of bonds well (a separate spreadsheet is kept), while UCIS does this function satisfactorily. PCSS has better support for some aspects of cashiering it calculates the fees due based on the document being filed (based on document codes) and it tracks fee waivers. It will also accept multiple payment types for one transaction (cash and checks) and split a check between cases. Neither PCSS nor UCIS is particularly strong in the area of cash drawer management, lacking several critical functions that one would expect to find for the sake of financial accountability, such as cash drawer balancing for each clerk, an audit trail, and user IDs stamped on financial transactions. There is too great an opportunity for defalcation with the present systems. If the clerk's offices become responsible for financial management (banking, returned checks, etc.) after the clerks of district court are brought into the judicial branch, more full-featured general ledger functionality may be required.
|Maintain arbitrator/mediator pool.||N||N|
|Maintain mediator/arbitrator availability.||N||N|
|Maintain arbitrator/mediator history of cases and results.||N||N|
|Set case on arbitration/mediation track.||N||N|
|Create strike list.||N||N|
|Remove case from arbitration/mediation track .||N||N|
|Record award settlement.||N||N|
|Management/statistical reports and listings.||N||N|
Although mediation is required in some cases, the court does not manage it. Neither system incorporates these functions, except as a tickler.
Management and Statistical Reporting
|Ad hoc inquiry and reporting (e.g., SQL), including user-selectable fields, sort criteria, selection parameters, linking multiple database tables.||N||N|
|View results of ad hoc query on-screen and print reports.||N||N|
|Export data to spreadsheet, merge document or in different data file formats (d-Base, comma delimited, ACCESS, etc.).||N||N|
|Pre-programmed calendar/case scheduling reports on-screen and printed.||Y||Y|
|Pre-programmed caseload reports on-screen and printed.||Y||Y|
|Preprogrammed case flow reports on-screen and printed.||P||P|
|Preprogrammed financial reports on-screen and printed.||P||P|
|Pre-programmed state mandated reports, (e.g. docket currency report) on-screen and printed.||Y||Y|
|Pre-programmed other case management reports by judge, by case type, by age of cases, etc. on-screen and printed.||P||P|
Both PCSS and UCIS rely on pre-programmed reports or lists that can be created using an inquiry function. The reporting is not as sophisticated as in many systems, perhaps because the caseloads are small and more easily managed than in large courts. There is no real ad hoc reporting capability and neither system gives the user the ability to export data to a PC where visual report writing tools could be made available. The docket currency reports required by the state are produced by both systems. The IT department of Cass County has also written additional reports that PCSS did not initially include.
General Systems Requirements
|Open systems or industry standards supported.||N||N|
|100% Y2K compliant.||Y||Y|
|Adequate security provisions to limit creation, viewing, updating and deleting of information.||Y||Y|
|Security provisions permit viewing data to be restricted at the case type level.||Y||Y|
|Remote printing available.||Y||Y|
|Codes, outputs, and other features are customizable by users for different court locations (e.g., different notice formats for each court, if desired).||N||Y|
|Archive and restore cases.||N||Y|
|Uses defaults (e.g., today's date).||Y||Y|
|Case number transfers to subsequent screens.||N||Y|
|Table-driven; look-up tables pop-up on screen.||Y||Y|
|Windows or other GUI functionality (e.g., cut and paste, menu/tool bar, navigation, multiple Windows open, etc.).||N||N|
|Password and clerk ID stored with data and retrievable to establish identity of operator.||N||N|
|Supports public access screens.||Y||Y|
|Easy navigation between functions and screens.||N||P|
|Codes can be de-activated but left in system for historical purposes.||N||N|
Both systems have substantial strengths when viewed from a systems perspective. Both applications are stable with minimal operational problems. Downtime is not a problem, response time is good and both are Y2K compliant. Considerable tailoring has been done on both systems to make them conform to the needs of the courts. The interfaces with other agency's systems are valuable in both UCIS and PCSS, and illustrate how these interfaces, if well executed and stable, can benefit both the courts and other agencies. In general, both systems assist users to do their jobs and provide a greater measure of efficiency for the clerk's office.
There are weaknesses apparent in each one, as well. Both are "green screen" systems based on IBM's proprietary AS400 technology. The proprietary technology limits the choices in development tools, database management systems, report generation software, applications architecture and other software. It may also be more costly, due in part to the yearly maintenance fees paid to IBM. While some people believe a character-based, green screen is an advantage for data entry, the consultants have seen many Windows-based systems used very efficiently in courts by data entry operators. It is important to recognize that more intuitive GUI interfaces help those who are occasional or new users, such as judges and administrators, to learn the system more easily and allow familiar users to navigate more quickly and conveniently.
The most serious drawback of UCIS is that it does not support tailoring options for different courts, such as the creation and production of different forms and notices. While we appreciate the need for uniformity, courts often differ in their sentencing terms and other local practices. Some flexibility, therefore, is warranted. The use of all uppercase letters and the limited formatting options also contributes to the look of an antiquated system, in addition to making these outputs difficult to read. The format and look of reports from UCIS is also quite difficult to follow (although "EZPrint" has now reportedly addressed this problem). Navigation through the system is a major issue for UCIS, which has a steep hierarchy of menus and does not carry forward the case number to the next screen. Neither system identifies data entered into the system by user ID, neither system has an archive and restore function, and the management of codes is very rudimentary in both systems. UCIS does not have register of actions codes at all.
2. Municipalities Using UCIS
Several municipalities are now using UCIS to support their municipal court operations. State Court Administrator (SCA) staff estimate that between 8 and 10 other cities would be large enough to have a potential interest in using the software. The UCIS software has been made available free of charge to the cities requesting it with the understanding that the city is responsible for running the software on its own computer and loading the updates as they are made available. The SCA staff provide some technical support and answer questions through the help desk. Until now, there has been no representation of the municipal users on the UCIS users committee and there has been no charge for services of the programs.
Several issues have been raised about the impact of municipal users on the SCA and UCIS itself. The discussion below brings out some of the implications of having municipal UCIS sites and suggests some policy directions or, at least, alternatives for consideration by the Technology Committee.
Should municipalities be permitted to use UCIS?
The policy to date has been to give UCIS to any municipality that can run the system for its city court. There does not seem to be any strong reason to change this policy, but as the number of cities increases, there are impacts and implications, discussed below, that must be considered.
Should the municipalities have a voice in development of UCIS?
A municipal court representative now sits on the UCIS users group as an observer. This representative will not have a vote on the committee. We think a non-voting role is the appropriate role for the present, but it is likely that the relationship between the city court users and the state court users will evolve over time. The needs of the city courts may change and this user group may not always be satisfied with a silent, observer role. We have some concern that the systems development priorities of the city courts and the state courts may be different enough to create some conflict eventually.
Should the municipal courts and the state courts continue to share the same version of UCIS?
For the present, there is no evidence of substantial divergence in the stated requirements of the city and state courts. It appears that the various courts can share programs. However, if the municipal courts require enhancements and changes that are not needed or are in conflict with the state courts, it may be better at that time to turn future development of municipal-UCIS over to a consortium of cities rather than try to maintain a common system. Another reason to consider turning this over to the cities is the increasing demand on SCA staff support.
Should the SCA continue to support the municipal courts using UCIS? Should the SCA charge for the programs or for technical support?
The SCA staff spends some time providing technical and user support, but the amount of time has not been tracked. Clearly the demand on SCA resources will increase, perhaps substantially, if as many as 5 additional cities go onto UCIS. However, if the SCA charges for services or the programs, it cannot use these funds to defray the cost of additional staff or supplies. The funds would be deposited in the state general fund. We do not believe the SCA should charge for the programs because they exist and the development has been paid for, nor do we think it is advisable to charge for services. Both would be meaningless gestures and would not defray any SCA costs for support of the municipal courts. It might also prove difficult to collect the bills at times, and then, what action should be taken if a city is delinquent in paying for support? If the SCA charges, will the municipalities begin to view the relationship differently and make demands as any customer would? Charging for this service may cause a great deal of trouble, while reaping no benefit for the state courts.
For the time being, the SCA should continue to support the city installations of UCIS. However, the SCA should track the amount of staff time used to support the municipalities. If the staff time is significant and detracts from support for the state courts, the SCA should seek to off-load support functions and development to a consortium of cities. An alternative would be to have the cities jointly defray the cost of a technical support FTE at the SCA, if a fiscal mechanism could be found to do this. Unless the city courts eventually come under the aegis of the state court system and unless the legislature is willing to fund the SCA to provide support to the city courts, it seem inevitable that the cities will eventually have to assume responsibility for their own CMS.
3. Integration of Case Management System Applications
Over and above the question of which case management system to use for each level of the court system is the question of what degree of integration among them would be appropriate and cost /effective. The systems in question are the Supreme Court's new Supreme Court Docketing System (SCDS), the new Juvenile Court Services system (JCMS) and UCIS.
Tight integration among the three applications, where the applications share a physical database or common programs, is not appropriate for these applications. Each is housed on a separate platform, uses a different database management system, (DBMS) and is, in all respects, a completely separate entity.
The consultants also considered the possibility of building interfaces between these applications to copy data from one system to another as the case moves between levels of court (district court to Supreme Court) and from informal to formal status (juvenile cases).(5) Technically, it is feasible to interface any of these systems to each other by creating programs to export data from one system to another. The data would be imported to populate a new case record at the time of case initiation (e.g., filing of an appeal). Despite the fact that either interface is feasible, neither of these interfaces would be cost effective simply because there are not enough cases filed in any one location of the court to justify the expense of building and maintaining the interface programs. When there are only one or two cases filed per day, the time savings would be negligible. For example, the Supreme Court consistently receives about 400 appeals per year, which is about eight cases per/week. There are about six data items that could be transferred from the UCIS system to SCDS(6), which can be entered in about one minute. The total time savings would be about eight minutes per week. The numbers are similar for juvenile cases. There are only about 2,800 formal juvenile cases filed in the entire state each year. No one county (7) has a caseload that would justify an interface on the basis of significant cost avoidance or increased productivity. Either interface would cost between $25,000 and $40,000 to build, using outside contractors.
4. Electronic Filing
Electronic filing can be defined as the transmission of case filing data, signatures, documents, and payment of fees (if required) in electronic form from a filing party's computer to the court's computer where the information is maintained and distributed in electronic form. The data accompanying the electronic document is generally identifying information about the case, the document being filed, the parties and the attorneys. The data is formatted to suit the court's case management system. The CMS receives the data, creates a new case or records the filing of a new document in an existing case and stores all elements of the case file in an electronic case file. The case file never exists in hard copy form. It is stored, retrieved and updated electronically. A hard copy can be printed, if needed. Some e-filing applications operate over a link between two systems, such as between a court's computer and a state's attorney's computer. Some are Internet-based (the Internet is the transport mechanism) and others use dial-up access. Most applications are one-way streets data are sent from the party to the court. In some applications, the court's computer may return something, such as an electronic order, acknowledgement of receipt of the document or a notice of hearing.
One of the first hurdles to overcome is the electronic signature. States that permit fax filing without the original document to follow are halfway to a solution. A change in the North Dakota Rules of Court allowing the clerk to accept electronic documents and electronic signatures would still be needed. The second hurdle for applications involving civil cases is the payment of filing fees. Generally, this is handled by accepting credit cards.
The best candidates for e-filing generally have the following characteristics:
A high volume of cases is filed with one court by one agency.
The active life span of the case is short.
The documents to be filed are short.
The documents are available in electronic form as ASCII text.
The agency filing the cases has an automated case management system.
No filing fees are required.
The retention period for the case file is less than 10 years.
Applications that have these types of characteristics have been developed and are operated successfully and cost-effectively in other courts. For example, in Orange County, California, the Superior Court has established an electronic filing application with the Department of Human Services for determination of paternity in IV-D cases. The system files cases electronically and the order establishing paternity is returned electronically. The great advantage of applications meeting these criteria is that they dispense with paper and the opening of physical files for large numbers of small, routine cases. Volume is the key to cost-effectiveness. In addition, because the documents are short and in a standard format, there is little to read from the screen, eliminating the problem of eye strain many people report when working with on-screen documents. Retention period is important because case files cannot be stored indefinitely on electronic media. Electronic media of all types deteriorate over time and are not considered good archiving mediums by the National Archives.
We do not recommend that North Dakota consider establishing e-filing for general civil cases because many civil cases are not filed until the case is ready for trial. In addition, we are not convinced that the Bar in North Dakota is ready to support e-filing across-the-board. Although there are attorneys who are technologically sophisticated, many are not, and it is not clear that this situation will change radically within the six-year window covered by this plan. We are also not convinced from interviews with clerks, judges and attorneys that judges are willing to read lengthy documents off the screen as a normal practice. An e-filing application will not be successful if the documents must be converted from electronic storage to paper because the clerk's office would be turned into a copying factory. The cost of an e-filing system for general civil cases would run in the millions. It is hard to see where the payback on that scale would come from.
Based on interviews with judges and staff and on our analysis of the caseload and interactions between the courts and other justice agencies in North Dakota, we believe there is some potential in the future for e-filing applications between the district courts and:
the Highway Patrol (citations);
the FACSES system (paternity and child support cases);
the State's Attorney's Office for misdemeanor DUI in some of the larger counties (Cass, Burleigh and Grand Forks).
These applications are targeted toward specific cases which have many of the characteristics described above. As far as we know, none of the agencies is currently ready to embark on an e-filing project with the court, but the Office of Management and Budget (FACSES) and Highway Patrol seem to be the best potential candidates during the timeframe of this plan.
5. Document Imaging
Unlike the electronic filing application described above, document imaging is a technology or tool that may be used in specific applications. For example, in e-filing applications, imaging is one of the formats that may be used to store documents electronically. Generally, when people refer to "document imaging" as an application, they mean an electronic document management system, which uses imaging as the sole or primary means of storing documents. This is the definition adopted for purposes of this report.
When considering using a particular technology, it is best to first understand in what situations it is most beneficial and what its drawbacks are before determining whether it fits a particular application. We begin with the assumption that North Dakota courts want to use technology to improve service to the public and the administration of justice in a cost-conscious manner. Some of the facts to keep in mind when evaluating the use of imaging for any particular purpose are:
Scanning documents you receive in hard copy is a labor-intensive process, which adds a time delay between receipt of documents and availability, as well as adding significant cost to the preparation of documents for use.
Imaged documents stored on CD, tape, diskette or other electronic media may become unreadable after a decade or so because these are not archival quality media. To permanently store imaged documents, they will have to be transferred to microfilm.
There are different image file formats, which may change over time. Equipment and software must be maintained to read older file formats, unless these files are converted to the next generation of software and hardware at additional cost.
The "best" document management applications are those for records that are accessed frequently. Simply scanning every document as it comes to the court is not cost-effective.
The cost of a document imaging system can be justified if it eliminates direct costs labor, rent for off-premises records storage, etc.
Far better security can be maintained over documents in electronic form than paper or microfilm.
Electronic documents can be linked to and made accessible from the register of actions of a case management system.
Establishing an electronic document management system is a more or less permanent commitment. Backtracking from electronic document management can be expensive, if records stored in the system must continue to be accessible. Generally, to be cost-justified, there needs to be a cost-avoidance pay-off that is big enough to off-set the greater costs. Alternatively, the system needs to be able to improve service or streamline workflow in a critical area so dramatically that the extra cost is worth it. Such applications do exist in courts, but generally they have been found to be cost-justified in larger courts or in special circumstances where workflow is greatly improved and the document management system is combined with another application that improves the efficiency of the court dramatically. The Los Angeles Municipal Court achieved dramatic cost savings and greatly improved records management with their Traffic Records Imaging System. Orange County Superior Court Probate Division achieved substantially better workflow and accountability using a document imaging system integrated with a probate application. We did not see any areas of court operations in North Dakota that we believed would justify the cost of a document imaging system at this time.
6. District Court Case Management System Recommendations
Phase 1 Recommendations
The Supreme Court should promulgate a policy that all district courts are required to use the state-supported case management system selected by the Judiciary Technology Committee.
When House Bill 1275 takes effect, all clerks of district court will be required to follow standards and procedures established by the Supreme Court. Most will become employees of the state judicial branch. In addition, the state judiciary will assume responsibility for all technology-related expenses and systems. It is reasonable and most cost-effective for the Supreme Court to establish, through the Technology Committee, standards for technology systems and services. North Dakota should support one district court case management system. To support duplicate systems, in the absence of any compelling reason, would be too costly and inefficient from a statewide perspective.
The Technology Committee should designate the Unified Case Information System (UCIS) as the single case management system that will be supported for the district courts statewide. Other CMS software in use throughout the state should be phased out.
The rationale for this recommendation is based on the following assessment:
1. UCIS and PCSS are the two candidate systems because they are both used successfully in the state. The alternatives of selecting a commercial package or developing an entirely new system were considered, but the ideas were discarded, for the present, due to the cost of changing software (about $2-3 million statewide) and the need for a viable solution that can be implemented during the 1999-2001 biennium with the available budget.
2. Both UCIS and PCSS have strengths and weaknesses. Neither is vastly superior to the other overall, although each is better and more functional than the other in some respects.
3. Overall, UCIS and PCSS are more similar to each other than they are different. Both have been used successfully in North Dakota district courts and have been tailored to the laws, practices and record keeping of the state.
4. With some (albeit, different) modifications, either system could form the basis for a good, functional statewide application.
5. The state should have one CMS, not two or more because the judiciary cannot afford the cost of duplicate systems. Therefor, one of the two leading candidate systems should be selected. We recommend UCIS because:
Adoption of UCIS as the statewide system will be easier, faster and less costly than converting the state to PCSS.
This path will require less retraining of staff throughout the state, less data conversion and no licensing fees for the rest of the state (a big cost item).
The judiciary developed the UCIS source code and can make modifications at will rather than pay and be dependent upon the software vendor.
Bringing Cass County into the UCIS system will provide the incentive for much-needed improvements to UCIS.
Prior to Cass County converting to UCIS, the UCIS system should be modified and enhanced substantially. Cass County should participate in determining which changes to UCIS are necessary prior to conversion and in designing and testing the changes.
The recommendation to convert Cass County to UCIS is not made lightly or without an understanding of the difficulties and disappointment this will cause the court and the clerk's office in Cass County. The staff and judges have worked very hard to make their system functional, and have achieved a system that has many fine aspects, tailored specifically to the court. The interface with the state's attorney is efficient and convenient for both organizations. There will be a great deal of concern in Cass County that UCIS will not support the operations of a larger court effectively. Although we understand these concerns, we believe they can be ameliorated. We have found no reason why UCIS cannot handle the volume of cases in Cass County and why it cannot be enhanced to make it comparable to the PCSS system.
The evaluation of both systems performed as part of this project illuminated several areas where PCSS has the superior capability or functionality. In our opinion, clerk's office operations will be greatly impacted by converting from PCSS to UCIS, unless significant enhancements and modifications are made to UCIS first. Cass County staff and judges should be included in the design, development and testing process to ensure that this court can successfully convert to UCIS. We recommend that the UCIS Users Group and Cass County staff review the function tables in the sections above and the recommended functional enhancements in the list below to agree on a list of the enhancements that are needed before Cass County converts to UCIS. It would also be useful for Cass County clerk's office and court administration staff to receive some initial hands-on training on how to use UCIS so they can determine how they would "translate" their work procedures or if changes are needed to tailor UCIS to Cass County's requirements. We also hope that all state court personnel will recognize that having Cass County join the state system is an opportunity for North Dakota to use the proven ideas of an innovative county to improve the system that will serve all courts.
The recommended enhancements to UCIS are listed below. Each is considered critical:
1. Review the menu structure and lateral navigation paths in the system, especially among screens that are necessary to complete a common process, such as case initiation or setting a case on the calendar. Re-work the navigation to make the system more efficient and to enhance workflow. Case number should follow to successive screens, until changed.
2. Substantially enhance the notice and forms capabilities to enable each location to enable the user to choose a standard notice or form, or to customize its outputs. Add the generation of file labels.
3. Modify UCIS to use docket codes for documents, events, actions. The register of actions should include the user filing/requesting party code, the date of filing or action or event (defaulted to today's date), the docket code, standard text and dollar amount. Docket entries should be able to be modified by the user by typing over or inserting new text.
4. Develop an interface to exchange data between UCIS and the Cass County State's Attorney's PCSS system. This interface should be functionally equivalent to what now exists in the county. Although we recommend a general State's Attorney interface in Recommendation II-6, this particular interface is needed to replace the specific connection in Cass County.
5. Review the indexes and reports available from UCIS. Add reports, indexes and inquiries to satisfy the needs of Cass County, especially the ability to use user-specified parameters to limit search criteria or the scope of a report. Greater flexibility in reporting would benefit others throughout the state as well, but is particularly critical to larger courts.
6. Review the financial functions for possible enhancement. Modifications are recommended to the cashiering area to automatically calculate fees due, to split one payment between two or more cases, to accept more than one payment type for a transaction and to accept credit card payments. Improvements to increase accountability for cash are also recommended (user ID on all cash transactions, cash drawer balancing by clerk, blind balancing, etc.). Accounts receivable seems to be adequate, but should also be reviewed in more detail to ensure that it is satisfactory.
7. Review the scheduling and case setting functions of UCIS to determine if they are able to support the court's case setting policies. We attempted but were unable to observe the UCIS automatic scheduling capability in various on-site demonstrations. At minimum, the automatic scheduling function in UCIS should be fixed.
8. The UCIS calendars also should be upgraded, and more user-defined formatting options made available. For instance, criminal calendars do not currently reflect the charge, and some judges prefer to sort calendars by age of case or type of hearing. A survey of judges would identify desirable calendar features.
1. Recommendation I-4
All district courts should operate UCIS from the SCA AS400 computer in Bismarck.
Grand Forks is the only court and clerk's office currently using UCIS that is not operating it from the SCA computer. Moving Grand Forks onto the SCA computer will be complicated because of the interface between UCIS and SAMS that, at present, is operational only when the two applications are on the same computer. The interface will have to operate remotely before this site is able to migrate onto the Bismarck AS400. This recommendation is made to avoid the cost of having Grand Forks provide computing services for the court after the state assumes responsibility for the clerks of the district court.
Phase 2 Recommendations
Develop a judge's module for UCIS using a Windows interface. Make this available to judges on the bench and in chambers.
Although some judges have embraced technology and are now comfortable with using it, most judges are not entirely up-to-speed. In general, judges first learn to use word processing, e-mail and legal research systems, all of which are available to district court judges using Windows-based software. The "green screen" UCIS operates completely differently and may seem like an alien system to many who are acquainted with the ease of use of Windows software. Few judges have received any training in using the case management system and are unable to use UCIS. Judges who cannot navigate the system to find the information they need are dependent upon their staff or the case file.
Many judges have found that their needs are both simpler and more complex that other court users. At least, their needs are more focused on certain types of information. The best CMS applications incorporate some screens that are designed specifically for use by judges. Some of the uses judges make of a CMS are:
to look up their own calendar;
to view the availability of a colleague to take a case for them;
to see the status of a case;
to see which of their cases are behind docket currency standards;
to find out which attorneys represent the parties in a case;
to make notes on a case at trial or a hearing;
to determine whether a document has been filed; and
to generate statistical reports (pending caseload, case flow, case aging, etc. for the court and individually).
The screens in a judges' module are usually inquiry screens, containing the type of information of interest to a judge on the bench (e.g., an on-line calendar) or in chambers (e.g., case status).
Development of a judges' module would serve two purposes: to provide a convenient and accessible tool for judges to use in managing their work and to acquaint the SCA technical staff and state court personnel with development of a Windows front end for the AS400 DB2/400 database. This Windows development experience may be valuable in the future for development or acquisition of the next generation of case management system.
We recommend two models of good judges' modules in vendor-developed case management systems: ISD Corporation (CA) and Automated Government Systems (owned by National Systems & Research, CO). Vendor contact information is available through the National Center for State Courts website at http://www.ncsc.dni.us/NCSC/VENDOR/Vindex.htm
Phase 3 Recommendations
During the 2003-2005 biennium, re-assess the future viability of UCIS.
The evaluation of UCIS performed as part of this study shows that from a functional perspective UCIS meets many of the needs of the North Dakota district courts. It has weaknesses, many of which can be corrected or ameliorated. Most staff are used to UCIS and the consultants heard only sporadic complaints, which were directed at specific functions or the "green screen" technology. Clearly, North Dakota district courts can continue to function on UCIS for some years to come as long as IBM continues to support the AS400 platform and RPG programmers can be found. Although it would be most desirable, from many standpoints, to consider acquiring a new case management system now rather than later, it is more important to bring all courts onto a common statewide system as quickly as possible. The cost of acquiring and implementing a new case management system would also exceed the budgetary resources of the next biennium, and therefor, it is not a viable short-term option. Although these reasons are overriding, there is a downside to continuing to maintain UCIS when it may not be the system of choice, eventually. One must look critically at creating interfaces with other systems because of the short-term cost and the fact that these interfaces will tend to complicate the decision to make a change in the CMS.
No decision remains valid forever, however, especially a technology-related decision. Eventually, as with all other legacy platforms and languages, the AS400 and RPG will fade into disuse or become too costly to maintain. While the database structure of UCIS appears sufficient to meet current needs, the future soundness of the database may be another consideration that would warrant a change. The courts should re-assess whether UCIS is the right system for the future during the 2003-2005 biennium. Based on our knowledge of the vendor-supplied CMS products available on the market today, staying with UCIS for the near-term seems to be a solid choice. The commercial offerings have changed and improved greatly over the past four years, and they may take another quantum leap over the next two biennia, as well. If there are no CMS products that fit North Dakota courts well at that time, UCIS could be converted to client/server architecture, with a GUI front end and more modern database management system, integration with a commercial word processor and commercial report-writing package.
In conjunction with planning for the new case management system and e-filing applications, conduct a detailed feasibility and cost/benefit analysis of electronic document management systems.
The recommendation not to go forward with an electronic document management system at this time is based on a lack of apparent need and no indication that any typical court applications would currently be cost-effective in North Dakota. This recommendation needs to be re-visited later because the costs of technology are dropping yearly. What is not cost-effective today may become cost-effective tomorrow. Also, e-filing applications involve some form of electronic document management, and taking a second look at a broader system encompassing more types of cases may be warranted if combined with e-filing. The organization of the state court system is also changing and may undergo further changes as the population of the state continues to concentrate in urban areas. If the experience of other states is an indication, it becomes increasingly difficult to maintain court services in rural areas. If the organization of the courts shifts toward services provided at fewer locations within a judicial district, it may be that keeping the services available to rural populations demands more electronic communications and perhaps electronic document management systems would perform a valuable service in making court files available.
Plan to develop e-filing for selected case types after the next generation of case management system is implemented.
Four e-filing applications mentioned earlier would be good candidates for e-filing applications. None of the agencies that would be the primary interface are prepared to move ahead at this time, but they may well be ready if the groundwork is laid in advance. We are also wary of suggesting that the small staff of the SCA, with a limited budget, try to accomplish more than the ambitious agenda already outlined for the first two biennia. A better timeframe would be when the new case management system is implemented to allow the CMS to be optimized for integration with this type of application.
C. Jury Management
1. Current Environment
A jury management system is in use to varying degrees in 34 of North Dakota's 53 counties. The system is Windows-based, written in dBASE. It can interface with any Windows-based word processor that can read dBASE files, and is currently used with several versions of WordPerfect and Word to prepare summonses, letters, mailing labels, and statistical reports. The system was developed in 1993 and Beta-tested in Morton County. The current pool of potential jurors will last until January, 2001.
Potential juror names are entered into the system in two ways. Drivers license information from the Department of Transportation (DOT) is provide by DOT on a floppy disk. Voter information is entered manually by the jury clerk the source information is not available in an automated format. The clerk entering voter names skips those who already have a driver record on file. The jury system calculates what the interval of names should be to get the right number of potential jurors (for example, every third or every fifth name).
The clerk receives completed questionnaires back from potential jurors and enters the information into the system using the mouse or keyboard. The system presents appropriate menus for different data fields. For example, if the clerk selects "not qualified," a list of reasons appears and the clerk can make a selection from among them. If a person is temporarily excused from jury duty, the clerk enters a new notification date and the system adds that name back into the potential jury pool on the new date.
When selecting a potential panel, the system randomizes the names and assigns a juror number. If desired, the clerk can reassign numbers after a panel is selected, so the panel has a smaller set of consecutive numbers.
The system calculates how much is owed each juror for mileage and daily jury service and prepares a list for the agency that issues checks.
The system creates statistical reports showing appearance rate and reasons for disqualification, among other things.
The system appears to provide appropriate functionality, but we observed stability problems that should be addressed as a mid-range priority when the current system's pool of jurors is depleted.
Although court staff using the system expressed satisfaction with the software, it did not perform smoothly during the one-hour demonstration attended by the project team. During that hour, the system froze several times and had to be re-started, and throughout the demonstration printed numerous pages of reports that had not been requested. This appeared to be a common occurrence that staff has learned to overlook.
Before the current pool of potential jurors is exhausted in January 2001, the state should purchase an off-the-shelf jury management program.
While correcting existing problems with the current jury management system is an option, the demands on IT staff will be high for the myriad of other existing and future data systems. Unlike the current state of vendor-developed case management systems, there are several very serviceable jury products on the market that not only provide functionality for current needs, but also contain features that may be considered for future needs (such as problems with low juror yield, or the need to print parking passes with a summons).
Several programs exist that have been tested in courts of varying sizes around the country, at prices ranging from $500 per installation to over $15,000 per installation (the latter includes sophisticated hardware). A few examples of vendors include Automated Government Systems (AGS); Jury Systems, Inc., with Jury+ (www.jurysystems.com); Manatron, Inc. (www.manatron.com); and the Omni Group, with JUROR for Windows (www.omni-group.com).
The system selected should:
Merge multiple juror source lists and purge duplicate names.
Edit the information available to eliminate obviously unqualified people from the potential juror pool.
Handle either a one-step (qualification and summons in the same mailing) or two-step process to accommodate county preference.
Interface with the word processing software of the Judiciary's choice for creating forms, notices, reports, etc.
Have customized statistical reports as requested by the user and ad hoc reporting capabilities.
Perform jury accounting procedures, such as determining the amount owed each juror for mileage and daily service and preparing auditable payment lists.
The current jury software performs most of these functions adequately for the North Dakota courts. Options to be considered for counties with larger volumes include:
Bar code capability ability to scan a juror's identification badge at jury assembly. This eliminates manual data entry of which jurors appeared as summoned.
Manual or automated scanning of juror response cards to determine eligibility. This function eliminates the need for staff to read every response card.
Automatic printing of parking passes and/or transit passes for transmittal along with the summons.
Zip+4 software to allow for the capture of Zip+4 information from a separate database, to reduce postage costs and to provide an accurate determination of mileage to the courthouse.
D. Internet Applications (Mini-Data Warehouse)
All courts should consider the implications of service delivery afforded by application of Internet-based programs. There is strong potential to substantially increase access to justice when court information is available from the comfort and convenience of a personal computer, 7 days a week, 24 hours a day. However, courts should not limit Internet-based applications to merely inquiry access; the challenge is to migrate court services onto the World Wide Web. Court forms should be downloadable; fines and fees should be collected by credit card; and compliance with court processes should be as easy as filling out and submitting a form online.
For a sample of outstanding court-related websites, we offer JUSTICE SERVED choices of the top-10 sites at www.justiceserved.com. At this site, we also offer a "model" court site that contains some of the functionality that courts should consider when examining Internet applications.
The North Dakota Judiciary is one of the recipients of our award for top-10 court related websites. The Supreme Court and legal information features are worthy of note. However, the highest impact for the public will be interactivity with District Court processes. The SCA should strongly consider a more active role by IT staff in the development and maintenance of the current website, while continuing to utilize the talent and creativity of those responsible for the current state of web design.
Insofar as substantive recommendations, we see the greatest need to use the Internet for two purposes:
a. To minimize the impact of expanded access to UCIS by outside agencies, by making browser-based access through either the Judiciary's Internet or Intranet; and
b. To create a mini-data warehouse for the purpose of attorney and public access to UCIS case information through the Judiciary's Internet.
While we address the implications of access by outside agencies in Recommendation II-1, the implications of a mini-data-warehouse are discussed below.
2. What is a Data Warehouse?
The data warehouse is the next step in the evolution of information systems that are host-based, terminal-driven, time-shared applications and based upon complex operational databases. These databases generally provide little information to managers and planners with higher level information requirements. Organizational information extracted from those earlier systems requires intimate knowledge of the data and extensive computer experience. The move to a data warehouse shifts the user paradigm from information providers to information consumers, those who are administrators, business managers and executive policy makers. Typically, data warehouses have the following characteristics:
Data warehouses are designed to satisfy the needs of managers and business users and not day to day operational applications;
Warehouse information is clean and consistent, and is stored in a form managers can understand;
Unlike operational systems, which contain only detailed current data, warehouses can supply both historical and summarized information; and
The use of client/server computing provides data warehouse users with improved user interfaces and more powerful decision support tools.
The data warehouse concept, driven by technological advancements and market
OLAP - On Line Analytical Processing, generally characterized by high volume transactions in a client/server environment, which may involve fragments of data from throughout the enterprise where the information is needed for strategic decisions;
DSS - Decision Support Systems serving information requirements that are not time critical, and which may be constructed using rapid application development (RAD) tools with a graphical interface; and
EIS - Executive Information Support systems that are more powerful, more business and organization specific, and easier to use than DSS.
As enterprises became more global, and warehouses grew in size and complexity, architectural variation arose to meet these new functional requirements. While a wide range of architectures exist, and the list of software suppliers is large, more than 100 vendors, our advice for the North Dakota State Court Administrators Office is keep it simple. First, state courts in North Dakota constitute a small universe for a data warehouse. Second, considerable, relevant implementation experience exists in the private sector for courts to draw upon; and third, the move has been away from architecture and designing the "ultimate data warehouse" to meeting specific user requirements by starting small.
3. Uses of a Data Warehouse in the North Dakota State Court Environment
Courts have always had warehouses of archival and operational information but with very limited access and retrieval capability. However, with the migration from paper-based to computerized case management systems, the door has opened to a rich world of information valuable to court managers, those involved with judicial administration, and the larger community of researchers and policy makers.
Typical uses of a data warehouse for the courts include the following:
Annual report type information, with both time series and cross jurisdictional, comparative statistics on types of cases, numbers filed and disposed, and processing times, although with more granularity;
Quantitative reports on legislation, both as to the effect on court workload and consequences to the community;
Court workload expressed in terms of scarce resources such as judge time, with projections of future workload based upon more sophisticated models;
Service demand on courts presented by institutional litigants such as collection agencies, insurance companies, large credit-extending retailers; and
Reports and projections regarding the potential effects of federal and state programs in areas such as child support enforcement, family welfare, and juvenile justice.
Besides providing the typical information delineated above, data warehouses can provide a variety of solutions for problems faced by the North Dakota State Court Administrators Office:
1. Public, court, states attorney and private attorney access can be provided utilizing a data warehouse with limited but necessary data and by developing applications to provide the information on the Internet.
2. Several external interface issues can be resolved by providing access to critical information for other agencies in the data warehouse and presenting it via the Internet.
3. Statistical reporting issues can be resolved by taking information from Grand Forks, Cass County and the UCIS statewide information and integrating the necessary information into the data warehouse.
4. The data warehouse could potentially provide the vehicle for later data conversion to a vendor provided system.
5. Data warehouse benefits can become more powerful when case information is joined with information from other sources. This is most obvious in the criminal justice community where the effects of legislation and law enforcement are felt by courts, corrections and a variety of social service agencies. The data warehouse can be used to provide an external interface with other agencies.
4. Implementation Strategies
The challenges to implementation of a data warehouse design are:
Source diversity - data may come from many different sources and court systems and will need to be reconciled.
Data quality - frequently legacy systems have little or no definition of field content with free format text fields housing docket entries, orders, and other important data.
Data integration - data may come from systems with different logical models.
Data transformation - coded fields must be translated to common court terms.
Complex movement processes - file extracts, transfers and load/update mechanisms can be quite challenging, especially when coupled with the source diversity mentioned above.
Solution scale - as value is realized, demand increases and it is common to see a tenfold increase in warehouse volumes over a 12-18 month period.
Tool integration - vendor product integration is increasingly a common, albeit complex, requirement; we will touch on some of this in a later section.
Project management - project failures are more often associated with poor project planning and management than with technological failures (see Recommendation III-10).
The initial design for the data warehouse is not the most important step. Perfection is not possible. Focus on the process first and the data second. Be more concerned with defining a process that allows for adding and deleting data sources over time rather than on the existing set of data. Define the goal to be "adding incremental value to the users", perhaps every three to six months, instead of building the complete solution. Rid yourself of the notion of the perfect solution. There is no "perfect" data warehouse since users needs will change and success requires that the data warehouse meet user requirements.
The SCA should create a mini-data warehouse. Begin the process by identifying the users and their information requirements. This should cover a considerable range of users of both public and private data. With the paucity of data historically available, the user base and requirements can shift radically, so plan for an incremental build incorporating change and growth. Availability creates demand, so expect user requirements and the number of users to grow.
There are more than 100 suppliers of software for data warehouses. The vendor listed Number 1 in 1998 by DM Review was IBM. Additionally, IBM's Visual Warehouse is available for OS/400. IBM's Visual Warehouse will allow the courts to start a data warehouse using a DB2 Universal Database with a full range of tools supporting organizational intelligence and allow the court to take advantage, over time, of the emerging standards for meta data integration and interchange.
The model below depicts the administrative and managerial functions of Visual Warehouse, together with the integration with many other vendors' products. This comprehensive approach and the commitment to standards are the basis for our recommendation.
External interfaces with the Central UCIS system, serving five of the seven judicial districts, are limited at present. There are no interfaces between or among the two UCIS computers (Grand Forks and SCA in Bismarck) and the PCSS site in Cass County. Some information is downloaded onto the Central AS400 (monthly Department of Transportation (DOT) names and addresses) and some information is uploaded (weekly dispositions to DOT). UCIS/PCSS workstations have access to the FACSES database but data entry is performed to the two systems separately (with minimal redundancy). The State's Attorney system (SAMS) is operational on the Grand Forks AS400 where it communicates and shares data with the UCIS system resident on that computer and is apparently in various levels of usage in approximately ten counties.
The PCSS system in Cass County communicates and shares data with the State's Attorney. Some (but not many) Probation and Parole officers have access to court system information in their jurisdictional area. No courts have any access to State Corrections or Probation and Parole databases. There is no external interface with the Highway Patrol. Bureau of Criminal Information (BCI) criminal history files are not electronically updated with disposition information from court computers nor is warrant and protective order information electronically transmitted from courts to BCI for law enforcement use.
The Supreme Court has implemented a substantial web site providing extensive Supreme Court information, including case opinions (with search capability), rules, court calendar, etc., to attorneys and the public. However, the only access to case information is through the UCIS public terminals in several of the county courthouses.
1. Access to UCIS
Provide inquiry-only access to UCIS to Corrections, Probation/Parole, State's Attorneys Offices, Bureau of Criminal Information, Highway Patrol, and other law enforcement agencies. (Phase 1)
Interviews revealed that Corrections staff would benefit from access to UCIS and PCSS databases for some Correction and all (not just the current few) Probation & Parole staff, particularly for fines, fees and costs information (restitution as well, if a court Clerk is handling restitution) and for hearing dates. Corrections' management would welcome court access to Probation/Parole (adult and juvenile) and correctional facility information systems but that access would be limited to exclude confidential information contained in those systems. Electronic transmission of notices for Pre-Sentence investigations, sentencings, revocation hearings, etc. (and, perhaps, even the electronic submission of pre-sentence reports) would result in timelier and better (and more formalized) communication between courts and Corrections. Since BCI files, accessible by both courts and Corrections, include a flag indicating current (open) cases with Probation/Parole it may be possible for courts to electronically provide Corrections with early notice of new arrests and possible probation/parole violations.
In large counties the state's attorney usually has access to the applicable UCIS or PCSS files. In small counties, possibly with part-time state's attorneys, there may not be computer access to anything. In any event, if the state's attorney in any county, large or small, wants access to UCIS or PCSS he/she should be advised by court administration how to have such access, what it can provide and how to get appropriate training in use of the system.
All communication between the Highway Patrol and the trial courts is currently in paper form. Major activity between Highway Patrol and the courts is the provision of uniform traffic citations and an occasional criminal case (through the State's Attorney). In addition, Highway Patrol also provides the courts with a monthly officer schedule. The Highway Patrol is currently working toward the in-car writing of tickets on mobile terminals and is interested in pursuing the possibility of providing that basic information to courts in electronic form, saving additional data entry responsibilities for both organizations.
The Highway Patrol receives notices for officer court appearances and orders regarding the requirement that they destroy records that the court has ordered expunged, all of which could be transmitted electronically. Highway Patrol also would like to receive case disposition information for HP initiated cases (traffic dispositions go to the DOT database to which they already have access but which is notoriously slow updating.)
Bureau of Criminal Information
In addition, BCI could use access to UCIS and PCSS in order to determine the result in a number of older cases in their criminal history files. At present they must telephone to the applicable court and ask the Clerk to look up the information. Direct access would, therefore, be of benefit to both organizations.
There is no question that providing inquiry access to UCIS by these outside agencies will increase the demand on IT staff, especially relating to the help desk and end-user upgrades to UCIS. Therefore, IT staff should consider using development tools that enable access to the UCIS database by outside agency users on an Intranet which would only require end user browser software and IT staff-issued passwords.
Provide public access to District Court data on the Internet. (Phase 2)
All of our interviews indicated a desire to provide public, commercial and attorney access to the court databases in order to provide better service to the courts' clients and to reduce the heavy load of inquiries received by the courts at the counter, in the mail and over the telephone. However, there is currently no public, commercial or attorney access to any of the three court information system sites serving the seven judicial districts (except for a limited number of public access terminals). The cost and effort required to provide modem access to the Central UCIS system is apparently the only deterrent for public access to the information of the five judicial districts housed at the Bismarck site. Interviews in Cass County revealed that sealed record information currently remains on the PCSS database because of the extensive effort needed to electronically seal information in that system. This makes public access to the data of the court with the heaviest volume of activity in the state unavailable until this problem is addressed. Investigation of the opportunities presented through a consolidation of the three court databases and utilization of a simplified access method to a limited file on a court web site should be a priority (see Recommendation I-10).
2. Department of Transportation
Build a real-time interface to DOT's system to replace the download of the 526,000 driver license records each month. (Phase 1)
Although Central UCIS users reported being quite satisfied with the monthly download, it is clear that a significant number of changes to the database will occur each month that could affect the accuracy of the information used to populate the court's file with basic ticket case information. The most up-to-date possible information is available on-line and a real time interface is available since many courts already have on-line access to the database for driver history information. This real-time information exchange effort could be the pilot for determining the difficulty and possible problems to be encountered in the numerous other real-time justice system data sharing efforts that are contemplated for the AS400. Programming modifications will be required to implement this change and response times will be affected. The cost and benefit of those changes should be thoroughly evaluated before undertaking the change.
Expand electronic transmission of traffic case disposition information from courts to DOT and standardize (or translate) disposition reporting codes to significantly reduce the rejection rates currently experienced by DOT. (Phase 1)
The Central UCIS system and a number of municipal courts using UCIS currently transmit traffic case disposition information to DOT electronically. Surprisingly, Cass County, with the greatest proportion of the traffic ticket activity in the state, does not currently provide electronic dispositions to DOT. Further, the rejection rate for submissions from those jurisdictions that do supply electronic disposition information is extremely high as a result of many courts, particularly municipal courts, using codes different from those used by DOT. The use of a simple conversion table at each automated site could eliminate a substantial number of those rejects reducing the DOT workload substantially. Further complicating the process and reducing the timeliness of DOT driver history information (unnecessarily in our opinion) is the DOT procedure requiring the matching of the paper tickets with the electronic information before allowing entry of the disposition data into the DOT database.
Investigate the possibility and/or practicality of electronic transmission of information regarding juvenile driving offenses and child support orders affecting the driver's license. (Phase 2)
The interview with the DOT representative revealed an interest in determining whether juvenile driving offense disposition information and child support orders affecting the driver's license and, possibly, other court determinations affecting the driver's license might be available electronically.
3. State's Attorneys System
Identify the data elements and data format UCIS must receive from a prosecuting attorney's system to populate a criminal case record. (Phase 1)
The interchange of data electronically between the state's attorneys and the court, which can result in the substantial reduction in court data entry and improvement in data accuracy, appears to hinge upon the extent that SAMS will be adopted by the elected state's attorneys in each county and the ability of the SAMS software to communicate across hardware platforms. (There reportedly are from 10-12 State's Attorneys that are or will be using SAMS out of the possible 53 counties.)
SAMS has been in various stages of development for approximately six years and it does not appear that it will soon, if ever, become the case management system of choice for the majority of State's Attorneys. The Judiciary does not have control over what software State's Attorneys use; however, it can, and should, state the requirements for interface with the court's case management system.
The State Court Administrator's Information Technology staff, in conjunction with a court user group, should request the State's Attorneys ensure that any case management system they install has specified data available in ASCII format to populate the court's criminal case information screen. The data should include defendant's name and identifying information, arrest and release information, charges filed, prior convictions, and any other information the Judiciary desires that is available from the prosecuting attorney. Real time transfer of this information would be preferable, however, periodic batch transfer would be far more timely, efficient and effective compared to the current paper process.
4. Other Government Agencies
Provide useable electronic criminal case disposition information (including the arrest tracking number, or ATN) to BCI to improve the timeliness and completeness of criminal history information. (Phase 2)
Although the Central UCIS system electronically provides ASCII criminal case disposition information to BCI, it is not currently used because case disposition information is the responsibility of state's attorneys by statute. Although originally intended to save clerical effort for clerks' offices around the state, the electronic submission of that information via the information system capabilities of the seven judicial districts, through UCIS and PCSS, could save substantial data entry time and cost for BCI and form preparation for Clerk's offices. Further, elimination of the need to report via the State's Attorney should result in more accurate, complete and up-to-date criminal history information for the entire justice community.
As the current statutory requirement places reporting responsibility with the state's attorney, there are two options that should be considered in order to implement this recommendation:
a. Seek a statutory change to place the reporting responsibility with the court; or
b. Simultaneously report the criminal history to BOTH the state's attorney and BCI, to enable the state's attorney to exert quality control over the reported data.
If the Judiciary pursues this recommendation, there is a need for the courts to capture and transmit the law enforcement ATN in order to facilitate the matching of a court disposition to an arrest. Otherwise, the problem of matching a disposition to the original charge(s) can be extremely difficult due to the significant charge changes that can occur during the legal process.
Build an electronic interface between UCIS and BCI to enter warrants and warrant rescissions into the BCI files to provide the most accurate and timely information. (Phase 2)
Warrants are reported by the Clerk of Court to local law enforcement which then has the responsibility for entering the warrant into the BCI warrant file used by law enforcement statewide. Rescissions are entered in the same manner. The public and the entire justice community would benefit substantially from the faster and possibly more accurate and complete entry of that information.
Evaluate the practicality of providing electronic data sharing between courts and law enforcement for protective orders. (Phase 1)
Currently, the petition for a protective order is, by necessity, created manually, and the applicant subsequently appears before the reviewing official. These processes preclude the need or usefulness of electronic transmissions at the beginning of this process. On the other hand, once the order is signed, the speed with which it can be entered into the BCI system and forwarded to the appropriate law enforcement unit for service is critical. The early posting of the approval of the petition and later, the notice of service having been made, as well as the rescission of a protective order, are all activities that should be considered for electronic transmission and posting.
Encourage the electronic transmission of law enforcement case information to courts (traffic) and State's Attorneys (criminal cases). (Phase 3)
The fully integrated justice information system starts with the collection of law enforcement data that then successively populates State's Attorney, Court and Corrections databases. The courts should be leaders in the effort to develop interfaces between systems and should encourage law enforcement to automate and share their case information. Prime examples of successful efforts at sharing electronic case information are the use of electronic ticket writing devices (such as those used in Ventura County, California) and the use of mobile terminals in patrol cars to initiate the police incident report. Although the preparation of charging documents via the mobile terminal is still in the experimental stage, numerous jurisdictions prepare and forward law enforcement charging documents electronically to the prosecution and/or court (such as the Philadelphia, PA PARS system).
Investigate the possibility of electronic transmission of requests for mental health evaluation and/or alternative treatment as well as for reports from the mental health service to the court. (Phase 3)
All communication between/among Clerk, Judge and Mental Health facilities is currently performed via paper with a small number of notices being forwarded to the Mental Health facility by FAX. The low volume, the use of a local service provider and the need for judicial signature make this process a poor candidate for early electronic transmission of information in Burleigh County. On the other hand, in other more remote counties using the state facility in Jamestown as their service provider, there might be effective use of electronic notification of the request for evaluation or for alternative treatment from court to facility and the provision of reports from facility to court. At some future date when a large number of the State's Attorneys are automated and have an electronic connection to UCIS, petitions might be sent electronically similar to the transmission of new case information.
5. Private Attorneys
The Bar Board should frequently provide a complete and up-to-date attorney file to the Central UCIS. (Phase 1)
The Bar Board maintains the "official" attorney file and feeds a weekly update to the web site. A copy of the file was at an early date provided for the Central UCIS system. Updates to the Central UCIS attorney file appear to be just additions and corrections and are made without reference to the Bar Board database that is up-to-date for new admissions, dues payments, suspensions, disbarments, etc.
Modify the court rule to require attorneys (not the 15-20% of pro-se filers) to file the electronic copy of their brief in a current version of Word or WordPerfect only. (Phase 2)
Attorneys are required by rule to file a diskette of their brief along with the paper briefs and the justices use the diskettes, especially while on the road (instead of carrying the paper). Although the rule was intended to focus on Word and WordPerfect submissions, there are many other formats received (consistent with the wording of the current rule) requiring a conversion effort by the Clerk's Office staff.
A. Office Productivity Recommendations
The District Courts of North Dakota do not have a uniform word processing program about 75% of them use various versions of WordPerfect, with the rest using (Microsoft) Word. Most users are pleased with their current program, but many have expressed a willingness to use whatever the judiciary selects as its word processing program.
WordPerfect is considered the standard word processing program in the legal community, and many judges are familiar with it. Judges' staff have built macros (automated tasks) in WordPerfect for orders, letters, etc. The State's Attorneys software, SAMS, uses a specific version of WordPerfect to create documents. However, the Attorney General's office says SAMS might also be able to be programmed to interface with Word.
As much as possible, the North Dakota judiciary should decide on a single office productivity software program. This will allow different offices to share documents easily, and will also allow the judiciary to more easily install other software, such as a case management or jury program, that interfaces with a word processing program.
Both Word and WordPerfect are consistently good products with a stable history. Both have new versions that allow the user to effortlessly save documents in HTML format for Internet or intranet applications. However, the Microsoft Office 2000 suite of programs has some advantages over Corel's WordPerfect Office 2000. For instance, documents saved in WordPerfect can be more easily converted to Word format than vice versa. And the spreadsheet and presentation components of the Microsoft suite, Excel and PowerPoint, are the industry standard. PowerPoint and Excel are used extensively in the IT office, the court accounting office and elsewhere in the Judiciary. In addition, the Judiciary is using Microsoft Exchange as its e-mail software.
For those users who are not prepared to move to Word, WordPerfect remains an option and should be accommodated.
B. Data Disaster Recovery Recommendations
1. Hardware Availability and Reliability Issues
Procure a redundant power supply for the AS 400 server when a product becomes available for this model. Backup power sources, whether they be uninterruptible power supplies (UPS) or power generators, should be tested every six months to ensure that they work when they are needed. (Phase 1)
The AS400 currently operated by the court is very reliable. It has software that identifies problems and notifies IBM personnel. IBM then notifies the courts and repairs the problem. The county operated sites that we visited also lauded the AS400 for its extreme reliability. One county user indicated that their system had not failed in three years.
The two subsystems on servers most likely to fail are the hard disks and the power supply. Superior reliability in these systems is achieved by redundancy. Redundancy and fault tolerance are built into the state AS400 which uses the RAID 5 approach with eight disk drives. The same redundancy and fault tolerance are built into the NT servers at the state office. If one drive fails, the others take over and continue running the system. The disk drives for the AS400 can be "hot-swapped," which means that the failed drive can be replaced without shutting down the server. Once the drive is replaced, the system begins recreating the database on the new drive, which can degrade performance on the entire network. Scheduling the replacement during low use periods takes care of potential user service issues. However, they are much slower than the current machine. Also, dial-up service with local or 800 number access is available to the state AS400 if local area systems fail.
Court computer operations in Fargo and Grand Forks reside on county-owned and operated AS400s with similar capabilities to the state machine in Bismarck.
The network on which all AS 400 and NT servers function is controlled by the state Information Services Division (ISD). The ISD maintains a "hot site," a secondary computer system that can be operable quickly if the state main frame computer fails. However, hubs and routers on the state network have very limited backup power supplies.
Backup power supplies are in place giving the court servers an hour of operation in the event of power failure. A backup power generator is in place in the state office building in which these servers reside. However, the system has never been tested. A redundant power supply should be purchased for the AS 400 server when a product becomes available for the current model, or any future upgrades.
2. Data Disaster Recovery Plan
Develop a data disaster recovery plan for information resources under the direct control of the North Dakota State Court Administrator's Office. Consider backing up to the State's mainframe using their ADSM product. Examine fire suppression options (including the use of Halon) for the room where state servers operate. (Phase 2)
Though a disaster recovery plan exists for the state-owned ISD computer systems, none exists for the North Dakota SCA systems. No contingencies are in place for dealing with the effects of fire, flood or tornado, the most likely data disasters in North Dakota. Of course, the use of Halon should consider its expense; however, the expense of a fire is often immeasurable.
Many good resources exist for developing data disaster recovery plans. They include but are not limited to the following web locations: www.summitonline.com/tech-trends/papers/ontrack1.html; www.snsinc.com/disaster%20recovery%20wp.htm; and www.storage.ibm.com/storage/software/adsm/adwhddr.htm.
3. Data Backup Procedures
Verify the last full backup of the court-operated AS400 once a month and test the backup system every three months. Test the Supreme Court backup system every three months. Verify that backup systems at other sites are tested every three months. Consider backing up the AS400 and the Supreme Court system to the State's mainframe using their ADSM backup product. Provide a fireproof, waterproof, anti-magnetic lockable storage case at all locations storing backups. Small, portable systems for home records protection are available at reasonable prices that should provide adequate protection. Require that the backup be stored in an occupied residence because of the potential damage that may occur to a backup tape left in a vehicle in extreme heat or cold. (Phase 1)
A full backup of all the information on the state servers located in the SCA Office is conducted every evening and stored in a vault on-site. Backup tapes are not verified. However, the backup procedure has been tested. One tape is stored off-site by an employee each week.
Full backups are conducted on the Cass and Grand Forks county servers once a week on Friday mornings. Incremental backups are produced each evening at these locations. The next to the last full back up is stored off-site by an employee each week.
Supreme Court backups are conducted daily and removed to the ISD secure storage location.
C. Training Recommendations
Create a full-time position with a court user background to serve as a training director. This position should also provide user analyst services to the current IT staff. The training director should develop court-specific systems training materials, including self-paced, self-directed training software available on the Judiciary network and CD-ROM. (Phase 1)
Purchase professional training and commercial training materials for common software such as word processing, web browsers and spreadsheets, to conserve in-house training staff resources for court-specific systems training needs. (Phase 1)
Training and support for UCIS users and users of other existing software for the courts needs to be significantly improved.
A help desk is provided in the SCA IT office to answer question for many users. Users are encouraged to e-mail or phone in questions they may have about the various systems. Help desk personnel answer the questions or direct them to other personnel who respond via e-mail or by phone. One part-time and one full-time temporary position (which may be upgraded to a permanent position) support the help desk. A training manual for UCIS has been developed and published both on-line and in book form.
Training and support currently in place include District Administrators and Site Administrators assigned to assist in training users of the various computer systems. It is important to note that training is only one of many responsibilities assigned to these individuals. It is difficult to provide on-going training for approximately 700 state system users, especially in a rapidly changing information systems environment where significant modifications and interfaces are proposed for UCIS, a new juvenile data system has been selected and a new jury system is proposed. The Judiciary IT staff does not currently support the PCSS court software in Cass County, but has responsibility for information services training and support in all other software and hardware areas. Additionally, the courts currently support both WordPerfect and Microsoft Word in a number of different versions, Windows 95 and Windows 98, plus ancillary programs such as e-mail programs, web browsers and virus scanning suites.
Periodically, training is scheduled and conducted; however, our review found a high number of UCIS users without adequate training. A substantial amount of UCIS functionality is underutilized because many users simply don't posses the necessary instruction for its use. UCIS enhancements recommended in this report, as well as the new juvenile and jury systems, will also be underutilized unless a systematic, concerted effort is made to improve user training.
Exacerbating this situation is the fact that many long-term employees were moved from manual systems to computerized systems in a very brief period of time with very little training. An additional complication is that the average age of Information Services personnel is under 30 whereas the average age of employees working in the court is somewhat higher. IT staff are typically college educated and highly trained in IT development and operation. However, they tend to have little knowledge or experience regarding the day-to-day operation of the courts they support. Court staff, on the other hand, are very experienced in court operations but often have limited knowledge or experience with information systems and computers. A culture of user support and training must be created in the IT office so court system users can weather the storm of technological change headed in their direction.
1. Data Security
Designate a security administrator in the SCA's office to review security issues, investigate security threats and maintain current knowledge of security issues including password administration, network security issues, viruses, data facilities security and other issues related to data security. Develop a statewide security plan for all data and computer resources controlled by the Judiciary. Ongoing, periodic security training for all court personnel should be developed or purchased, including self-directed, self-paced training software available on the Judiciary network and on CD-ROM. (Phase 1)
The security administrator should establish written agreements with all district and other facilities not under the court's direct control who provide computer services to the courts or who have access to the court's data to maintain agreed-upon levels of security. These contracts should specify the required level of security necessary for the courts. All private contractors working with the courts who provide data hardware or software services should be required to provide a written agreement to abide by security policies and procedures established by the North Dakota State Court Administrator's Office. (Phase 1)
With the advent of the Internet and rapid expansion in networks, security issues for courts have increased substantially in recent years. Research has shown that employees account for an estimated 50% of all security violations. Computer hackers are the second largest group of individuals causing security concerns. Though they are the second largest potential threat, the majority of damage to computer systems is perpetrated by this group. The viruses they create and circulate are the largest threat to security and productivity.
Several security issues exist for the various computer systems utilized by the Judiciary. No written statewide security plan exists. In our review of data security we did not find an SCA employee given the sole responsibility for security issues; instead, a group of people were given responsibility for certain areas of security. Additionally, data access agreements between the courts and providers of computer services seemed to be informal rather than formal. Written security agreements with contractors for hardware and software services were not found. Court employees are given initial, but not ongoing training regarding security and password protection issues. No procedures exist for dealing with security issues for employees who are transferred, terminated or quit. Reporting procedures by employees for security infractions are not in place. Consequences for security breaches are not established. A written policies and procedures manual for security issues was not found. No evidence was found that employees signed a specific agreement to abide by security procedures. Established procedures for review of security issues were not found.
Most of the recommended activities should occur in Phase 1 of implementation since they impact all current and future systems. In-house staff can implement these recommendations. Most large organizations have data security plans in place and many of those plans are available on the Internet. For example, the University of Minnesota publishes its security procedures and standards on the net at www1.umn.edu/oit/cco/security/security.html. Additionally, a commercial site for Security Magazine provides excellent information and downloadable articles regarding security issues and planning, www.infosecnews.com/. A review of the Internet search engine Northern Light revealed 3,523 potential sources on the new for "data security issues". Carnegie-Mellon University also has an excellent site regarding data security policies and procedures. The site can be found at the following location: www.policy.andrew.cmu.edu/univ_policy/documents/DataSecurity.html. One of the SCA network staff should be assigned responsibility for these issues. No additional personnel costs should be incurred in the implementation of these recommendations with the possible exception of ongoing security training. Even then, many public organizations have created presentations for this training and would quite possibly give permission to use their web-based presentations.
2. Computer Facilities Security
Facilities at the IT Office are open from 8:00 a.m. to 5:00 p.m., Monday through Friday, and regular access is monitored by staff. Access at any other time requires the use of an electronic access card issued to employees only.
The state AS400 server, backup servers and NT-based servers for the courts are located in the IT Office in a room for that purpose. Battery backups are also located in the same room. The room is lockable with a regular door knob lock and a deadbolt. Additional state NT servers are located at a number of county data processing sites adjacent to the county-controlled AS 400s. Security at these sites is similar to the IT Office in that access is restricted to employees with regular key access rather than electronic access. Public access to desktop PCs and terminals in state and district court offices is restricted since the public is not allowed entrance to work areas of these offices. Recommendations for the state server facility will be made in the section pertaining to Data Disaster Recovery.
3. Password Security
The Security Administrator should develop procedures to review passwords for all systems to ensure that they meet court guidelines. No additional outside costs should be incurred for this recommendation. (Phase 1)
Standard password rules have been implemented for users of UCIS. Password protocols for the AS400 allow users to be restricted in their access to the system. Passwords are set so users may only access that part of the system needed to do their job. Users must change passwords every sixty days. Passwords may not be ones used in the previous six months. They must be at least six characters in length. Password infractions are addressed as they are found. No consequences are tied to password violations.
E. Application Development Strategy
A number of options were considered before the Justice Served project team developed the recommendations contained in this report. In today's climate of moving from legacy systems to client server systems and Intranet/Internet based applications, the common call is for open systems that allow users and vendors to make changes and adjustments to codes and processes. Cross platform capabilities allow easy transferability of information, and in the ideal environment, software, from one platform to another. Host based systems are generally legacy systems with new functionality overlaid to give the systems a second life. An example is software that allows "green screen systems" to use a web-browser interface. Thin client systems use traditional server technology and give the advantages of main-frame based systems, that is, central control over all applications and ease of updates since all applications reside on the central server and not on the user machines. Additionally, thin client has the advantage of working with a wide variety of user equipment from terminals to older PCs or Macs. Internet-based systems can utilize host-based legacy systems, client server or thin client systems to deliver information via the Internet in a web browser format. This format is increasingly familiar to all users and is very easy to use.
All of these strategies have their proponents and opponents. Each option has its advantages and disadvantages. Our biggest concern in looking at these options is that they all imply that the SCA has the programming resources to develop systems. Our analysis suggests that scarcely enough resources are available to modify and support the current UCIS program. The preferred method for future development is more of an application acquisition strategy, where preprogrammed, supported, tested and highly functional software is purchased for specific purposes. Increasingly, more court-application software is becoming available at reasonable prices; these vendor software packages possess the functionality and flexibility required. We suggest that the preferred approach is to develop a process where user needs are clearly understood, and the IT staff then locates the software to meet these needs, thus moving the process from one of how to develop the application to how to acquire the best application that meets the needs of the users. Focus then moves to management of acquisition, implementation, data conversion, and training and support of users.
F. Project Management
Adopt a procurement model similar to the Canadian model for managing all outsourced IT projects and utilize appropriate aspects of the model for in-house projects. Pay particular attention to negotiating contracts and implementing "gating" and "off-ramping" procedures. Implement change management techniques to ensure successful IT project implementation. (Phase 1)
Project management responsibilities for this six-year (three biennia project belong to the IT staff in the State Court Administrator's Office. Traditional project management tools should be utilized for managing the overall project. These include project management software, Gantt charts, Pert charts, organization charts, performance-compared-to-budget analyses and milestone identification. A variety of project software tools are available. We have found Microsoft Project to be a good management package though it has a substantial learning curve. Using these tools, a management plan with personnel assignments, timelines, resource estimates and management reports can be developed for review by the State Court Administrator. Information can be displayed in a variety of formats, allowing a manager to examine a project from a variety of perspectives.
When an organization is confronted with significant technological changes in a relatively brief period of time, in this case six years, we suggest the following model be utilized for managing that change. This model is particularly effective when outsourcing court requirements. However, some of the tools involved in the method may be effectively used for managing in-house projects. The model is derived from a Canadian Information Technology procurement model. The model is described in detail below.
As public institutions, courts are subject to taxpayer safeguards, with prescribed procurement methods that are fair, equally accessible and achieve the most product for the least cost. Many times, these procurement methods are cumbersome and time consuming; often they do not achieve their intended purpose. Some describe the process as "seeking last year's technology in next year's budget." Court managers should consider all available procurement options before committing to a particular method to obtain technology. For instance, many jurisdictions have the ability to buy products costing less than a specified amount (for example, $10,000), as long as three to five quotes are obtained from competing companies. Also, it is possible to sole-source an acquisition (purchase through a single provider), based either upon a justification that no other vendor is capable of providing the required product, or upon a competitive bidding process that was conducted in a neighboring jurisdiction. Another alternative is to purchase from a vendor "on agreement," that is, a company that is pre-qualified and listed on a county, state or federal purchasing agreement roster for a particular product or service. The most common method of procurement for large IT projects is the Request for Proposal, or RFP.
Whether it is the RFP, RFI (Request for Information), RFQ (Request for Quotation) or RFB (Request for Bid), this method of procurement follows a similar format. It involves drafting a solicitation document that usually contains two parts: first, standard terms and conditions required by the court's funding agency, and second, a detailed "scope of work" or description of the product or services required. A common mistake in this process is to provide product specifications in the scope of work rather than a description of the problem and operating environment; for example, describing the specifications for a specific desktop computer, instead of indicating the need to manage a database of case-related information. As previously mentioned, a clear and accurate assessment of underlying problems is imperative to document needs for the scope of work. To save time, court managers are often tempted to plagiarize a dissimilar scope of work from another RFP used within the court or utilize a similar scope of work RFP issued in another jurisdiction. Caution must be used to model the best format, but not the same content. Test RFP readability with a disinterested party to ensure a clear and unambiguous meaning and format. Particularly useful are checklists that vendors may use to respond to the RFP. Clearly indicate the criteria for choosing the winning proposal. Because the goal of an RFP is clearly communicating the court's needs to the potential vendor, conducting a pre-bid conference should be considered. This provides an opportunity for proposers to ask questions and seek clarification of the RFP. In proven, straight-forward IT applications, a pre-bid conference may not be necessary; in complex and new applications, it is advisable.
Evaluating Proposals and Proposers
To facilitate evaluation, care should be taken to ensure that proposals are submitted in similar format. As described above, drafting the functional requirements in a checklist format makes it easier for the vendor to respond and improves comparison of bidders. Some method of assessing the track record of bidders should also be used in the evaluation of proposals. Normally, a list of customers from each vendor is obtained so that a survey may be conducted regarding customer satisfaction. The most common method of choosing a winning bid is the use of an evaluation committee. Clearly communicating what criteria will be used in evaluating proposals, and including this in the RFP, promotes proposals that highlight critical deliverables, and guides the evaluation committee in properly judging the candidates.
Although procurement appears to be an adversarial process, it is important to develop a contract that is a win/win situation for the court and the vendor. Contract negotiations should provide both a legal review to protect the interests of the court and a reality check regarding what is feasible. No contract has ever been developed that takes every circumstance into consideration or addresses every contingency. Disagreements will occur later. Include in the contract a clear statement of how disagreements will be addressed. Issues such as who calls a meeting, who sets the agenda, and how conflicts are to be resolved should be included in the contract. Only substantive and major issues should be addressed in a contract. A negotiating time table should be established to facilitate timely contract negotiations. The contract, above all, should be clear and direct, with a mutual understanding of the expectations on both sides of the table.
Developing a contract in the above fashion sets the stage for the use of two particularly effective management tools, "Gating" and "Off-ramping." "Gating" and "Off-ramp" provisions divide an IT project into segments with the clear understanding that the contract parties meet at these occasions to review progress to date, and to decide what course corrections need to be made to ensure the continued success of the project. If serious breakdowns have occurred, an "Off-ramp" is used to cancel the contract and proceed with another plan; if reasonable adjustments are advisable, the project proceeds through this "Gate" with the expectation that another review will occur at a later specified time.
These procedures resolve quality assurance issues for the various projects in the following way. Divide the recommendations into biennium budget periods (mid-point and end of biennium), at which time you measure progress against the original plan. Make adjustments based upon the reviews. Since your IT plan is revisited in January of every even numbered year, which is approximately half way through the biennium, this provides a natural mid-point for utilizing gating and off-ramping procedures.
The lawyers have gone, the procurement officials have returned to their offices, and the budget staff has completed their tasks. Now the court manager is left with the court staff and the vendor, each attempting to put into action a product or service to cure the problem. Let's review some of the procurement steps that will be useful in the implementation process.
First, a study has been conducted of the initial problem for the purpose of drafting the RFP, including a review of the underlying procedures; make every effort to reengineer and streamline the procedures to maximize the effectiveness of the new technology. Second, a review of available technology has uncovered similar applications in another court environment or discovered a similar business process. Borrow the best practices from these other work environments to make your transition more smooth. Third, the RFP has accurately described the working conditions that need to be changed. Use this information to help the vendor reach a better understanding of what needs to be done. Fourth, the vendor contract has easy and blame-free mechanisms to address the questions and inevitable corrections that need to be made to successfully implement the product or service.
Finally, court managers should use "change management" techniques to assist implementation. Until everyone passes the learning curve and sees the benefits derived from improved processing, there will be uncertainty and conflicts that need to be resolved. No matter how powerful your new technology may be, it will be the needs and attitudes of the judicial officers, staff and other end users that will ultimately determine the success of your IT project. Analyze mitigating and aggravating forces affecting the project and devise strategies that address them. Identify local champions of the project and give them extra latitude. Achieve early "quick wins." Commit to the training and system support necessary to ensure success.
G. Quality Assurance
As a Quality Assurance measure, IT staff should address the projects recommended in this report within the context of the next three biennium budget cycles, as Phase 1, Phase 2 and Phase 3 priorities. Using the "gating" and "off-ramping" provisions described in Section III.F., Project Management, the progress of each project should be examined to determine that it is on track, if adjustments are required, or if a project should be cancelled. A natural milestone for this exercise is the biennial examination of the Judiciary's IT Strategic Plan, which occurs in January of each even numbered year. (Phase 1)
Many governmental agencies have begun to structure IT acquisition and IT projects to contain safeguards to prevent cost overruns, system failure, and loss of purpose. The North Dakota Legislature has addressed this matter by requiring a Quality Assurance provision in future IT projects. Accordingly, the Justice Served consulting team has approached this project to identify IT recommendations, prioritize these recommendations and align them into discreet, prioritized projects. In Chapter IV, we describe the projects and provide a matrix of estimated costs.
H. Statewide Justice Coordination
The Judiciary should assume a leadership role and initiate a statewide justice coordination effort to provide a forum for justice-related agencies to explore IT system acquisition and development that is compatible and, whenever possible, integrated. (Phase 1)
The Judiciary is at the center of a complex mechanism known as the justice system. Several ancillary agencies from multiple jurisdictions interact on many levels to fulfill their particular mission. As the Judiciary has turned to IT solutions to address productivity, these agencies, too, increasingly utilize computerization to manage their respective caseloads. A significant opportunity exists to coordinate the efforts of these justice agencies to ensure that IT system development and acquisition are compatible and, whenever possible, integrated. The information age has addressed the previous problems related to organization of paperwork, and supplanted these with new problems: excess data entry and the need for timely input of case-specific events. Creating linkages with justice agencies reduces redundant data entry, and speeds the updating of case information. Unless the Judiciary assumes a lead role to provide a forum for these linkages, the opportunity will be lost.
I. SCA Information Systems Staffing
Increase the number of SCA IT staff to recognize the increased responsibilities of Information Technology management, with a priority to add a position with a court user background for training and user analyst services. Add at least one contract programmer due to UCIS interfaces and modifications. (Phase 1)
There are several factors that justify increased staffing for the State Court Administrator's Information Systems office (IT staff):
Increased IT staff-supported users of UCIS, resulting from migration of Cass County from PCSS to UCIS, and migration of all other District Court users off of their county-owned AS400s to the state network.
Development efforts to improve the functionality of UCIS.
Additional users when the Judges' module is developed.
Acquisition and implementation of the new Supreme Court, Juvenile and Jury data systems.
Creation and maintenance of a mini-data warehouse for public and attorney access.
Development and maintenance of external interfaces with UCIS.
Increased maintenance involvement with the Judiciary's website.
Whenever practical, we identify the impact on IT staffing resulting from recommendations contained in this report. However, general discussion of this topic is warranted. First is the issue of outsourcing services versus hiring staff. Clearly, significant opportunities exist to contract with outside entities (public and private) to provide ongoing maintenance and support. For instance, larger counties such as Cass and Grand Forks have multiple UCIS users that are remote from the IT staff headquarters. It is advisable to develop service contracts with Grand Forks and Cass County data systems operations to provide user support for services such as hardware maintenance, communication service, loading of software, peripheral support and other services short of UCIS software functionality. In addition, contract programmers should be considered to augment IT staff for the purpose of enhancements to UCIS.
Ultimately, however, the IT staffing complement will have to be increased to recognize the growing responsibilities they will assume. One area of particular concern is the need for an IT staff position with a court user background to serve as a combination trainer, developer of training delivery, and user analyst. Otherwise, we recommend that ongoing maintenance and support services be outsourced whenever possible, to conserve in-house staff resources for those tasks with the highest potential impact on Judiciary productivity: systems development, systems enhancement, systems acquisition and systems integration.
MIGRATION, IMPLEMENTATION AND COSTS
This chapter contains substantive recommendations relating to Migration, Implementation and Costs. Most, but not all, of the various recommendations contained in Chapters I (Court Applications) and II (External Interfaces) of this report are aligned into projects that are described in this chapter.
The recommendations in Chapter III (Administration) are not aligned into projects, because they address administrative, strategic, project management, security and training aspects of IT management. Some of these administrative recommendations will have cost implications, which are noted in the third chapter. However, the focus of this fourth chapter is on IT projects that result from our review of Judiciary data systems and opportunities for integration.
A. Recommended Projects
A listing and description of recommended IT projects appears below. The particular recommendations that comprise each project are noted. Most, but not all, of our recommendations in Chapters I and II are aligned into these projects, which are also sorted by priority:
PHASE 1 PRIORITY PROJECTS
(to be completed in the first Biennium, 1999-2001)
PROJECT #1 UCIS Modifications
Resulting from Recommendation numbers I-1, I-2 and I-3
Description: Improve the functionality of the UCIS District Court case management system for current and future users. These enhancements are described in detail in Chapter I.
PROJECT #2 Upgrade the SCA operated AS400
Resulting from Recommendation number I-4
Description: Upgrade the SCA operated AS400 to enable the migration of Grand Forks and Cass Counties, as well as future District Court and ancillary agency users. There are substantial and increasing demands that will be placed on the SCA operated AS400 by virtue of legislated migration of current county operated computer operations. In addition, an increasing number of inquiry access users will be added in the near and intermediate future. The SCA must be prepared to address these additional demands.
PROJECT #3 Migrate Grand Forks to the SCA Operated AS400
Resulting from Recommendation number I-4
Description: Move UCIS case processing from the county operated AS400 in Grand Forks to the SCA operated AS400. Grand Forks is a large user of UCIS currently operating on county owned equipment. Migration to the SCA operated AS400 will facilitate system integration.
PROJECT #4 Public Access to UCIS Case Information
Resulting from Recommendation number I-10
Description: Create a "mini data warehouse" to contain limited current and past case information, primarily for the purpose of public and attorney access via the Judiciary Internet site. This warehouse will also be used to generate statistics and management information, and will eventually serve as a resource for data conversion to a vendor developed case management system that will replace UCIS.
PROJECT #5 Two-way, Real Time Updating of DOT Records
Resulting from Recommendation numbers II-3, II-4, and II-5
Description: Create a link with the Department of Transportation for the purpose of receiving up-to-date drivers license information, and to report traffic-related violations. These implications are more fully described in Chapter II.
PROJECT #6 Bar Board Attorney Information Updates
Resulting from Recommendation number II-12
Description: Create a link with the Bar Board to provide up-to-date attorney information to users of UCIS. These implications are more fully described in Chapter II.
PHASE 2 PRIORITY PROJECTS
(to be completed in the second Biennium, 2001-2003)
PROJECT #7 Migrate Cass County to the SCA Operated AS400
Resulting from Recommendation number I-4
Description: Move case processing from the county operated AS400 in Cass County to the SCA operated AS400. Fargo is the largest District Court in the state and currently uses the PCSS vendor developed case management software operating on county owned equipment. Migration to UCIS, and subsequent migration to the SCA operated AS400 will facilitate system integration. If it is possible to accelerate this project into Phase 1, every effort should be made to do so.
PROJECT #8 Develop UCIS Judge's Module
Resulting from Recommendation number I-5
Description: Develop a specialized module in UCIS with a Windows interface for use by judicial officers. This will be the first foray into a Graphical User Interface environment for UCIS.
PROJECT #9 Acquire Jury Management System
Resulting from Recommendation number I-9
Description: Replace the current jury management system with vendor software. There are several very serviceable jury management software programs available for purchase. These implications are more fully described in Chapter I.
PROJECT #10 Create UCIS Link with BCI
Resulting from Recommendation numbers II-8 and II-9
Description: Provide a direct link to the Bureau of Criminal Information for the purpose of updating criminal warrant and conviction information. These implications are more fully described in Chapter II.
PHASE 3 PRIORITY PROJECTS
(to be completed in the third Biennium, 2003-2005)
PROJECT #11 Re-assess Future of UCIS, E-filing and Imaging
Resulting from Recommendation numbers I-6, I-7 and I-8
Description: Conduct an assessment of the cost and functionality of vendor developed case management software before embarking on expanded development of UCIS. Short term enhancements to UCIS are justified and necessary, but long term expenditure of IT staff and budgetary resources should consider the return on investment of acquiring vendor developed case management software in the third biennium.
B. Matrix of Projects with Cost and Effort Estimates
Each of the projects enumerated above are described below in matrices that indicate the various tasks involved, who will be responsible, what their respective roles will be, the anticipated amount of time required, and the estimated cost. These matrices are intended to be working documents that are examined and refined as circumstances change and as additional information becomes available. Indeed, they should facilitate project management, budgeting and long range planning efforts.
Phase 1 Projects
Project #1: UCIS Modifications
Timeframe: 18 months during the 1999-2001 biennium
|Project 1: UCIS modifications|
|1. Design and development effort to substantially modify UCIS in several key functional areas to meet the needs of Cass County. Review the functional analysis of UCIS and establish a list of priorities.||SCA|
User design committee
Design, programming, testing, documentation
UCIS review, design, testing, approval
|2. Develop an interface between UCIS and PCSS, and UCIS and the Sheriff's system to replace the existing functions that permit data sharing between the Court and the State's Attorney's Office and the Court and the Sheriff.||SCA|
Cass County ISD
|Project organization, oversight|
Design, programming, testing
Testing environment and technical assistance
Project #2: Upgrade the SCA AS400
Timeframe: 3 months in the 1999-2001 biennium
|Project 2: Upgrade the SCA AS400|
|1. Sizing analysis upgrade to accommodate Grand Forks and Cass County Clerk's Offices and judges state-wide.||SCA|
Grand Forks and Cass County IT depts.
|Sizing analysis||1||Provided by IBM at no charge|
|2. Upgrade the SCA AS400 in Bismarck.||SCA/IBM||AS400 model upgrade/conversion, testing||2-3||$75,000 + increases in subscription, maintenance|
Project 3: Convert Grand Forks to the SCA AS400
Timeframe: 2 months in 1999-2001 biennium
|Project 3: Convert Grand Forks to the SCA AS400|
|1. Conversion activities.||SCA|
G. F. IT dept.
G. F. Clerk's Office
20 hrs- technician
Project 4: Public Access to UCIS Case Information
Timeframe: 8 months in 1999-2001 biennium
|Project 4: Public access to UCIS|
|1. Offer access explain process for getting it, advantages to having it.||SCA||Marketing||1-4||Ongoing effort|
|2. Training.||SCA or District Court staff||Develop training plan and curriculum; deliver training to users||2-6||Minimal|
|3. Connect agencies to AS400/open access to UCIS.||SCA||2-6||$200 per user|
|4a. Develop Mini Data Warehouse.||SCA|
|Contract for consulting and programming services||4-8||$30,000|
|4b. Acquire Database Software.||SCA||Purchase||2-4||$175,000|
|4c. Make information available on Judiciary web site.||SCA|
|Run Internet site||8 |
Project 5: Two-way, Real Time Updating of DOT Records
Timeframe: 10 months in 1999-2001 biennium
|Project 5: Provide a two-way, real-time interface with the Department of Transportation drivers license records|
|1. User requirements analysis, systems analysis, design of interface.||SCA, User group, DOT|
|Project management, user requirements|
|2. Programming, testing, go-live.||Contractor|
Project 6: Update UCIS Attorney Table via Tape from State Bar Association System
Timeframe: 4 months in 1999-2001 biennium
|Project 6: Update UCIS Attorney Table|
|1. Requirements analysis.||SCA|
|Project management, user requirements|
|2. Programming, testing, implementation.||Contractor|
Phase 2 Projects
Project #7: Migrate Cass County to UCIS and SCA AS400
Timeframe: 10 months during the 2001-2003 biennium (or earlier, if possible)
|Project 7: Migrate Cass County to UCIS and SCA AS400|
|1. Data mapping and data conversion from PCSS to UCIS.||SCA|
Cass County Clerk's Office
|Project mgmt. and oversight, technical assistance|
Analysis, programming, testing, conversion
Data/code mapping, testing, approval
|2. Develop training plan and curriculum; deliver staff training.||Contractor|
Cass County Clerk's Office and Court
|Develop and deliver training|
Assist with procedural review and training
|3. Monitor implementation||SCA|
Cass County Clerk's Office
Monitoring, re-training, quality control
Project #8: Develop and Implement UCIS Judge's Module
Timeframe: 8 months during 2001-2003 biennium
|Project 8: Develop UCIS Judge's Module|
|1. Design , development, testing.||SCA|
User design committee
Design, programming, testing, documentation
Technical assistance and advice
Review, design, testing, approval
|2. Training.||Contractor||Develop training plan and curriculum; deliver training to judges||6-8||$28,000|
Project #9: Acquire Jury Management System
Timeframe: 9 months during 2001-2003 biennium
|Project 9: Acquire Jury Management System|
|1. Develop requirements and RFP. Procure software and hardware.||SCA, Users Group||Project management, procurement||1-4||$25,000|
|2. Software modifications.||Software vendor||Analysis, programming||5-6||20 days X 8 hrs X $100/hr|
|3. Implementation: Data conversion and table set-up, hardware and software installation, training.||SCA|
|Hardware/software installation, data conversion|
Table set-up, data conversion, training
Project #10: Create UCIS Link with BCI
Timeframe: 12 months during 2001-2003 biennium
|Project 10: Provide warrant and case disposition data to the Bureau of Criminal Information system||Programming|
|1. User requirements analysis, design.||SCA,|
User group, BCI
|Project management, user requirements|
|2. Programming, testing.||Contractor||Programming, testing||6-9||$30,000|
Phase 3 Projects
Project #11: Re-assess UCIS and Determine Future Direction for State-wide CMS, E-Filing and Document Imaging
Timeframe: 6 months during 2003-2005 biennium
|Project 11: Re-assess UCIS Future Direction|
|1. Analysis of alternatives||SCA|
|Project mgmt./ coordination|
Assessment of UCIS, analysis of alternatives, recommendations, budget projection
Analysis, recommendations to Supreme Court
C. Administrative Recommendations Contained in Chapter III and Elsewhere
There are a number of recommendations contained in this report, most notably those in Chapter III (Administration), that are not aligned into projects, because they address administrative, strategic, project management, security and training aspects of IT management. Some of these administrative recommendations will have cost implications, which are noted in the their respective chapter. We summarize some of the implementation and cost implications below:
OFFICE PRODUCTIVITY (Recommendation #III-1)
Costs for the software are as follows:
|Microsoft Office 2000 CD||$ 21|
|Microsoft Office 2000 license (competitive upgrade, when moving from WordPerfect)||$ 171|
|Microsoft Office 2000 license (upgrade from previous version)||$ 136|
|Microsoft Office 2000 license (new user)||$ 230|
|Microsoft Office 2000 documentation||$ 18|
This project should be spread over all phases, beginning this year with courts that need to upgrade their word processing packages now. By the end of the third phase, all courts should be migrated to the new software.
Purchasing, installing and maintaining the software should be done by State Court Administrative staff.
DISASTER RECOVERY (Recommendations III-2 and III-3)
DATA BACK-UP AND SECURITY (Recommendations III-4 through III-9)
It is expected that IT staff be responsible to follow through with the recommended safeguards.
Glossary of Terms and Abbreviations
The following table contains common phrases, terms and abbreviations used in the body of the report, and is intended as a reference to assist the reader in better understanding the report.
|AS400||A proprietary computer platform purchased from IBM that operates from mini-computers. Most AS400s currently in service in the District Courts are early generation equipment that are only capable of operating software that is developed in an AS400 operating system language. Newer models of the AS400 are capable of acting as file servers and by using processor cards, are capable of running software developed in other than AS400 language.|
|ASCII||American Standard Code for Information Interchange, a common format for cross-platform exchange of computer data.|
|ATN||Arrest tracking number.|
|BCI||North Dakota Bureau of Criminal Investigation, responsible for maintaining criminal arrest and conviction information.|
|Byrne Grant||A funding source for various justice projects.|
|CD||Compact Disk, a data or program storage media.|
|Client/Server||A computer operating platform in which desktop computers (clients) are linked in a network and have access to system-wide software that resides in one or more dedicated computers (servers). Newer versions of this operating platform are considered easily adaptable to Graphical User Interface (GUI), and adaptable to a wide array of vendor-developed software, particularly those using a Windows operating system.|
|CMS||Case Management System, such as UCIS or PCSS.|
|DBMS||Database Management Software.|
|DOS environment||Disk Operating System (DOS) is a basic computer operating system that usually consists of limited-color screens and fixed data entry fields. DOS is contrasted with Graphical User Interface (GUI) which consists of multi colored screens, icons, mouse navigation, sizable boxes and convenient configuration.|
|Database, and database programs||A database is a collection of information. This collection is contained in a database program such as Microsoft Access, Microsoft SQL, Oracle, Fox Pro, or other brand/product name software.|
|DOT||North Dakota Department of Transportation, responsible for issuing drivers and vehicle licenses, and tracking information related to traffic citation and related convictions.|
|Dumb Terminals||Dedicated display devices or desk top computers that function as display devices through the use of terminal emulation software.|
|EFT||Electronic Funds Transfer, a wire transaction in which funds are deposited electronically to a bank account.|
|FACSES||Fully Automated Child Support Enforcement System operated by the North Dakota Office of Management and Budget for the purpose of tracking and enforcing child support orders for payment. FACSES runs on the state's mainframe computer.|
|"Gating" and "Off-ramping"||A project and contract management technique wherein a project or contract is divided into measurable milestones, at which performance is examined, adjustments are made and a decision is required either to continue or cancel the project or contract.|
|Graphical User Interface (GUI)||Graphical User Interface (GUI) is a commonly available environment found on most stand-alone desktop computer operating systems. It consists of multi colored screens, icons, mouse navigation, sizable boxes and convenient configuration. Currently, the UCIS, JUCIS, SCDS and Jury Systems operate in a DOS environment, which usually consists of limited-color screens and fixed data entry fields.|
|ISD||The executive branch state agency: Information Systems Department.|
|IT Office or IT Staff||Information Technology unit of the North Dakota Judiciary, or the staff who work in this unit.|
|JUCIS||Juvenile Court Information System - the current software program developed by the State Court Administrator's Office to automate case processing in the District Courts for juvenile delinquency and dependency operations. JUCIS runs on a proprietary IBM System/36 platform, except in Burleigh County where it runs on an AS400. A vendor-developed software program that operates on a client/server platform will replace JUCIS.|
|Jury Management System||A software program developed by the State Court Administrator's Office to automate jury services in the District Courts. This system operates either on stand-alone desktop computers or on a computer network (client/server), and is in current use in 33 counties. Although there are no immediate plans to change this system, it will eventually need to be upgraded or replaced..|
|NT or NT Server||A Microsoft Windows network operating system or a computer dedicated to the operation of a network utilizing the Windows software.|
|PCSS||A county-purchased, vendor-developed (PCSS, Inc) software program that automates case processing only in the Cass County (Fargo) District Court. PCSS runs on a proprietary AS400 IBM platform.|
|RAID or RAID 5||Redundant Array of Independent Drives, multiple drives in a network or server computer in which data is maintained simultaneously in the event that one or more of the drives fails.|
|SAMS||State's Attorney Management System, automated case management software made available to county-based prosecuting offices by the North Dakota Attorney General's Office. Ideally, criminal cases initiated by a prosecutor in SAMS should transmit case information to the Court's automated case management system to eliminate the need for double data entry.|
|SCA||State Court Administrator, or State Court Administrator's Office.|
|SCDS||Supreme Court Docket System the current software program developed by the State Court Administrator's Office to automate case processing in the Supreme Court. SCDS runs on a proprietary IBM System/36 platform, and is migrating to a client/server platform.|
|UCIS||Unified Court Information System - the current software program developed by the State Court Administrator's Office to automate case processing in the District Courts. UCIS is operating at most District Court locations statewide except for low volume courts that do not have access to the Judiciary's network, and except for Cass County (Fargo) which operates PCSS. UCIS runs on a proprietary AS400 IBM platform.|
|UPS||Uninterruptable Power Source (or supply), a back-up power battery or generator serving as a safety measure in the event of a power failure.|
About JUSTICE SERVED
JUSTICE SERVED is an alliance of court management and justice experts providing management services, consultation and training to courts and justice agencies. Our consultants are consistently leaders, experts and innovators in the court and court technology fields. We utilize many of the technologies being implemented in courts nationally and internationally, to operate our company, from word processing and presentation programs operated from standalone PC's to video conferencing and Internet applications that link us together as a world wide network. The president of Justice Served is Christopher Crawford, a court professional with more than 25 years of experience with judicial administration. Among the services available are:
MANAGEMENT SERVICES - Justice Served consultants possess the knowledge, experience and skill to successfully manage complex court improvement and technology implementation projects. Utilizing vast management experience and sophisticated management and software tools, Justice Served professionals customize our services to meet the needs of the client.
COURT PERFORMANCE - Above all, courts should be fair with their processes and open and accessible to the public they serve. The professionals at Justice Served have developed standards to measure court performance and are available to conduct a review to improve the integrity of the administration of justice.
TECHNOLOGY - Justice Served has the expertise to manage technology projects, perform assessments and make recommendations for applying technology to court processes to improve efficiency, effectiveness and public service.
PROCESS RE-ENGINEERING - Whether associated with a technology assessment or as a separate exercise, our consultants have worked in courts and are able to streamline work processes and remove bottlenecks. We use specially developed software to graphically demonstrate how improvements will affect operations.
FINANCIAL ANALYSIS - Courts and justice agencies generate a substantial amount of revenue. Justice Served is very successful at identifying processes and programs to improve collections and promote the integrity of court finances.
CASEFLOW MANAGEMENT - A prime mission of courts is to settle cases in a timely manner. We have extensive experience in calendar organization and caseflow management, and can offer effective recommendations to reduce delay.
STAFFING REVIEW - Justice Served will review current staff and deployment, and recommend efficient organizational structure and staffing levels.
JUSTICE AGENCY RELATIONS - Our professional have demonstrated experience working with other justice agencies that work with courts, to improve work processes, integrated services and electronic data interchange.
Please visit our website at www.justiceserved.com for complete information. Be sure to view our Top-10 Court Website Awards, downloadable research reports, links to other Websites of interest, and more. 1. 2. 3. 4. 5. 6. 7.
1.1 This report does not re-visit case management systems for the Supreme Court and the Juvenile Court Services offices because new case management systems have recently been purchased or developed.
2.2 House Bill 1275 has different provisions for the assumption of the clerks of court position by the state judicial branch, in some cases automatically, in other cases, at the option of the county.
3.3 And therefore, the question is whether either CMS is worth keeping or modifying.
4.4 Any type of activity can be set for a time when no court session has been pre-defined. For example, an emergency hearing could be heard at 8:00 am, before regular court sessions start, but not during the 8:30 am to noon session, if that session was not specifically earmarked for emergency hearings.
5.5 The interfaces discussed in this section differ from the electronic filing applications discussed in the next section in that this application involves the transfer of data only and no electronic exchange of documents. This application would not create electronic case files as would be created in an electronic filing application.
6.6 The data items are: UCIS case number, case title, plaintiff and defendant attorneys, date of filing and trial judge.
7.7 Cass County reportedly has the highest number of formal petitions per year: 438 delinquency + 107 dependency = 579 total petitions.