Albania Statistical Training Courts Prosecution Session 7 February
Albania Statistical Training Courts / Prosecution Session 7, February 1, 13. 15 – 14. 30 An Electronic Case Management System With funding from the European Union DEVELOPMENT OF MONITORING INSTRUMENTS FOR JUDICIAL AND LAW ENFORCEMENT INSTITUTIONS IN THE WESTERN BALKANS 2009 -2011
Case Management System (CMS) Do not underestimate the implementation of an Electronic CMS. Be careful not to be too ambitious. Start with a complete, detailed and accurate description of the workflows (and do not forget a good description of terms used and the flow of entities like offenders and cases through the system) • • Why do you want a CSM? What will it be used for?
Case Management System (CMS) Possible advantages of and use of a CMS: • • • Efficiency on the ‘work floor’ Uniformity in procedures Better quality of the data processed Planning of resources within court Better communication with other courts, ministry, statistics office, prosecution etc. …?
Case Management System (CMS) Possible pitfalls of a CMS: • • • High costs! Possibly more workload for clerks Too much freedom in ‘personalizing’ a CMS Lazy entering of data (using defaults) Quality control lacking …?
Case Management System (CMS) • • In the Netherlands we started development of an Electronic CMS in the early ’ 80’s for both prosecution and courts It took about 4 years and many millions And it failed miserably Only in about 1990 we had a working Electronic CMS In 2002 a redesign was needed This took about 4 years and many millions And it failed miserably
Case Management System (CMS) Lessons learned: • A CSM is both an organizational challenge and a complicated IT project • There is an enormous gap between IT professionals and legal professionals: – – IT’s want to redesign everything IT’s want to make it beautiful with lots of features IT’s do not understand the real needs of an organization Legal professionals do not understand the implications of what they want in IT terms – Legal professionals think their workload will disappear when they have a computer
Case Management System (CMS) Lessons learned: • Implementation of a CMS has a very steep learning curve: It takes a lot of effort and training to be able to work with it. • It is a sad truth that software systems never seem to work correctly, certainly not in the beginning • It is a sad truth that developing software systems takes always longer than suspected.
Case Management System (CMS) Recommendations: • Invest a lot of time and effort in describing exactly and formally the work processes. Before even thinking of developing software • Hire a group of highly competent IT professionals and train them first in getting to know all legal processes. These people should become the project management. • The project does not end when the software is delivered. Only when it is successfully implemented.
Case Management System (CMS) Recommendations: • Start small and slowly increment the system. • Do not hire a software company to develop the whole system. Hire programmers to do the job under the direction of your own project management. • The only alternative is to buy standard software. But then you have to adapt your CJ system! And implementation is a big effort anyhow. • Be aware that maintenance of the system is not to be underestimated. It is a big investment as well.
Case Management System (CMS) Recommendations: • Seriously consider to have one system for both prosecution and courts. Essentially you are doing the same thing: processing cases and making decisions on cases.
Four areas of using CMS • We can identify four areas of use of a CMS: 1. 2. 3. 4. • • Operational level Local management information (LMI) Central management information (CMI) National use for research and policy making (NAT) Typically, a CMS is built with primarily 1) in mind and possibly 2). 3) And especially 4) could easily be ‘forgotten’. One of the issues here is: in which area is detailed information on the record (case? offence? ) level needed and where is aggregate information sufficient?
Four areas of using CMS Operational level • Supports handling cases, the primary use of a CMS • Obviously detailed (record level) data needed
Four areas of using CMS Local management information • Information needed by the management of the court to regulate work processes. • Information typically needed: workload of individual judges, development in types of cases, cases pending etc. • Aggregate data are sufficient
Four areas of using CMS Central management information • Information needed by a Ministry or Judicial Council to establish and/or distribute resources needed. But also information given by the courts to give account of their activities • Information typically needed: workload of courts, development in types of cases, cases pending etc. • Aggregate data are sufficient
Four areas of using CMS National use for research and policy making • Information needed by a Ministry, Statistical Office and Research institutes to establish the working of the Criminal Justice System and to define future policies. Also to give account to the general public of the activities of the CJS. • Information typically needed: detailed information on cases: offender, victim, crime type, conviction, punishment etc. • Aggregate data are NOT sufficient, detailed data are usually needed
Extracting information from CMS The question is how, for the LMI, CMI and NAT areas, the data are extracted from the CMS. Six design decisions are important here: 1. 2. 3. 4. 5. 6. Direct access to the CMS or through an interface? Extracting of detailed data or aggregate data? Continuous or periodic extraction? Different extractions for each area? What data are exactly needed in every area? How to deal with privacy issues?
Extracting information from CMS First how this is organized in the Netherlands:
Flow of data, the Netherlands COMPAS: Administrative system used in 19 PS offices Information from appeal courts Special interface for CBS Mgmt Info System for 19 PS offices Interface for Criminal Record Register CBS Statistics Mgmt Info System for Central Prosecutor Office Central Criminal Record Register OMDATA (WODC) Crimes only Crimes and misdemeanors OBJD (WODC)
Extracting information from CMS The first three decisions are implemented as follows in the Netherlands: Direct Detailed data Continuous access (d) or (c) or Interface (i) Aggregate periodic (p) (a) LMI i a* p CMI i a* p NAT i d c and p
Extracting information from CMS The design decisions: 1) Direct access to the CMS or through an interface? Generally speaking, direct access is too heavy a burden on the CMS. Also, the IT architecture is more complicated. This could only be an option for the LMI.
Extracting information from CMS The design decisions: 2) Extracting of detailed data or aggregate data? Detailed, record level, data is only needed in the NAT area. However, also in the other areas detailed data give more flexibility.
Extracting information from CMS The design decisions: 3) Continuous or periodic extraction? – Continuous: Every time something important happens with a case (input, prosecution decision, court verdict, …) a record is written to an intermediate buffer. – Periodic: Once every month / week / … an extract is made from the primary system. Continuous is theoretically better, but more difficult to implement
Extracting information from CMS The design decisions: 4) Different extractions for each area? In practice, given the different needs, there could well be one extract/interface for LMI and CMI and another for NAT.
Extracting information from CMS The design decisions: 5) What data are exactly needed in every area? As an example, some of the data used in the Netherlands (for the CMI and NAT areas) are presented, followed by a discussion on what more could be needed or useful.
Extracting information from CMS The design decisions: 5) What data are exactly needed in every area? Data is structured in three ‘classes’: • Cases • Offences • Court hearings
Extracting information from CMS The design decisions: 5) What data are exactly needed in every area? Cases: 169 (!) variables, such as: • Data to identify the case • About 50 date variables (for all kinds of decisions) • Prosecution request and penalty imposed • Offender data (address, country of birth, age, …) • Several identifiers to link with other systems
Extracting information from CMS The design decisions: 5) What data are exactly needed in every area? Offences: 53 variables, such as: • Identification variables • Offence data (date, location, type of offence, non-juridical qualification, . . ) • Decision (Prosecution decision, court decision: guilty or not)
Extracting information from CMS The design decisions: 5) What data are exactly needed in every area? Court hearings: 47 variables, such as: • Identification variables • Date variables (date of court hearing, …) • Decisions of the court
Extracting information from CMS The design decisions: 5) What data are exactly needed in every area? More data needed: 1. Data on personnel (but only for LMI) 2. Non – juridical data / qualifications 3. Victim data! 4. … ?
Extracting information from CMS The design decisions: 6) How to deal with privacy issues? Is probably only relevant for CMI and NAT, and only with data extraction on record (case) level.
Extracting information from CMS The design decisions: 6) How to deal with privacy issues? Possible measures to be taken: • Encryption of identifying variables. Problem: linking with other datasets not possible, at least not with 100% accuracy. • Special statistics law
Albania Statistical Training Courts / Prosecution Session 7, February 1, 13. 15 – 14. 30 An Electronic Case Management System With funding from the European Union DEVELOPMENT OF MONITORING INSTRUMENTS FOR JUDICIAL AND LAW ENFORCEMENT INSTITUTIONS IN THE WESTERN BALKANS 2009 -2011
- Slides: 32
