Legal Information Model
3.1 Levels of Information Exchange between Organisations
3.2 Information Exchange Level 1 - Common Systems
3.2.1 Principle
3.2.2 Example
3.2.3 Common Systems between Judicial Greffe and Bailiff’s Chambers
3.2.4 Extending COURAS to Royal Court
3.3 Information Exchange Level 2 - Access to Systems
3.3.1 Principle
3.3.2 Examples
3.4 Information Exchange Level 3 - Interfaces Between Systems
3.4.1 Principle
3.4.2 Examples
3.4.3 Recommendations for Achieving Interfaces Between Systems
3.4.4 Common Identifiers
3.5 Degrees of Automation - Workflow Systems
3.6 Potential for Case Handling Workflow Systems
3.6.1 Royal Court and Jersey Court of Appeal
3.6.2 Royal Court with Links to Other Automated Systems
3.6.3 Magistrates Court/Youth Court/Petty Debts Court
3.6.4 Police
Many information flows in the Jersey legal system relate to cases (both criminal and civil) before, during and after Court. Most of the processes documented in the Information Model comprise case-related information flows, spanning a number of organisations. Information about cases is passed between different organisations at various points, creating duplication of information and the possibility of delays.
The high-level model, given in section 2.3, shows that cases go through a number of activities, involving several administrative units. For example, as defined in this model, a Civil Action can go through up to 5 processes:
· Represent;
· Initiate Civil Action;
· Run Court Service (impacting also on Resource Courts);
· Make and Publish Judgement;
· Implement Civil Judgement,
involving potentially 5 administrative units:
· 2 sets of lawyers;
· Bailiff’s Chambers;
· Judicial Greffe (potentially several Sections)
· Viscount’s Department,
whereas a Criminal Case might involve up to 8 processes:
· Provide Police Services;
· Represent;
· Remand Accused;
· Prosecute;
· Run Court Service (impacting also on Resource Courts);
· Make and Publish Judgement;
· Implement Sentence;
· Provide Prison and Probation Services,
involving potentially even more administrative units including:
· States Police;
· Honorary Police;
· Defence Advocate;
· Judicial Greffe (potentially several Sections);
· Law Officers’ Department;
· Bailiff’s Chambers;
· Viscount’s Department;
· Probation Service;
· Prison Service.
Each involves potentially many transfers of information from place to place, as detailed in the full Information Model presented in Appendix G. In many cases some of the information being transferred is the same, leading to duplication of effort and the possibility of error and delays.
The concept of "end to end" case handling is to reduce these overheads by handing on the relevant information at each stage electronically in a way (and in a format) in which it can be re-used by the next step, whilst accreting the additional information produced at each stage. "End to end" handling of cases is a major area where there would be prima facie scope for improvement. The principles are described in this section, and examples of opportunities are given.
It is recommended that JLIB:
· adopts the goal of "end to end" case handling;
· agrees a target timescale for achieving this;
· determines what methods for achieving this are appropriate in each area; and
· adopts a plan to schedule the activities required to achieve it.
This report focuses on using information systems for "end to end" case handling, rather than any wider aspects of case management. For example, we have not commented on whether a specific individual or agency should be responsible for managing and progressing a case through all, or part, of its life cycle - although the proposals presented here would provide an infrastructure which would enable that to be done if it were deemed desirable. (It is understood that the progress of civil actions is currently in the hands of the parties, and that the Judicial Greffe for example have no remit to prompt cases which are pending, other than after 5 and 10 years have elapsed.)
To move towards "end to end" handling of cases, two aspects of computer systems need to be considered:
· the level of information exchange between different organisations within the legal system; and
· the degree of automation of systems.
Section 3.1 introduces three different levels of information exchange between organisations, and sections 3.2 to 3.4 describe each of these levels and highlight specific examples and recommendations.
Section 3.5 introduces two different degrees of automation of computer systems, and section 3.6 gives illustrations and recommendations about the higher level of automation, known as Workflow systems.
3.1 Levels of Information Exchange between Organisations (back to top)
New technology allows processes to be improved and integrated across organisational boundaries without needing to change organisational structures. Rather than papers (or even emails) having to pass in sequence from person to person, it can be possible for many people to access the same document in different places; people in different offices can work on the same system. For example, the Police, Courts, and Probation Service are all separate organisations, but they do not all need to type in the same name, address and case history information.
Where processes can be integrated, information flows can be improved to give less duplication of clerical work, greater accuracy, and potentially greater speed. This report identifies ways of improving operational performance within existing organisational structures.
There are potentially three levels of information exchange between organisations:
· Level 1: Organisations share the same computer system
· Level 2: An organisation is given read-only access (or other limited access) to parts of another organisation’s computer system
· Level 3: Information is sent from one organisation’s computer system to another organisation’s computer system, across defined interfaces (while each organisation retains full control of its own system).
Each of these will be appropriate in different circumstances. They are discussed in sections 3.2 to 3.4 respectively.
It is recommended that this three-level model be adopted (or adapted) by JLIB as a framework for monitoring and guiding developments in legal information systems in Jersey. The related recommendations in 3.4.3 and 5.1 concern guidelines for implementing this.
The fullest type of integration between organisations is where they share the same information system. It may be feasible for computer systems to run across existing organisational boundaries in this way where there are no constitutional objections and no "Chinese walls" are required between them.
The main area where it is recommended consideration is given to systems operating across organisational boundaries is the Magistrates Court Greffe, the rest of the Judicial Greffe, and the Bailiff’s Chambers. These organisations represent broadly the same interests (the administration of the Court system) and so it may be that issues of separation of constitutional function, which might prohibit joint departmental systems in other cases, do not create a barrier here. This is illustrated at Figure 3.
Sections 3.2.3 and 3.2.4 describe aspects of this.
As for other aspects of the legal system, the optimum allocation of responsibilities between these organisations is outside the scope of the present study. However, regarding information systems, unified access to common data between the Greffe and the Bailiff’s Chambers may be a worthwhile principle. This could be at the core of the Workflow system recommended in 3.6.1.
The Magistrates Court Greffe has recently implemented an electronic Court listings and document management system, COURAS. As this system is currently being rolled out, it is recommended that its potential to be extended to be used in the Royal Court is examined.
As both Courts share some functions in common, there could clearly be benefits in both using the same systems (for example, the production of Acts of Court and sending them to common recipients).
A common diary system between the Courts for Court officers might also enable flexibility of staffing of, for example, Transcribers and Ushers between the lower Courts and the Royal Court. (The same could in principle apply to Greffiers, although it is recognised that this would involve more significant requirements for cross-training.) In the shorter term, access to the Magistrates Court COURAS system from the Judicial Greffe could go some way towards facilitating this.
However, the recommendation in 3.6.1 for a Workflow system in the Royal Court should be taken into account alongside the potential for extending COURAS.
In the next level of information exchange, an organisation may allow another organisation read-only access (or other limited access) to parts of its computer system, where the information is freely available to that organisation.
The most obvious examples would be for the Greffe and/or Bailiff’s Chambers to give read-only access to parts of its system(s) to other agencies such as the Viscount’s Department, States Police, Law Officers’ Department, Probation Service, or private law firms. A case where this already takes place is that the Judicial Greffe, the Viscount and Attorney General’s Chief Clerk have read-access to the electronic Court Diary for the Royal Court, which is managed by the Bailiff’s Secretary.
Figure 4 illustrates the States Police and Viscount’s Department having read-access to a central Court information system.
We have not explored the details of the constitutional relationship between different organisations within the legal system, but clearly many of these organisations represent different interests or have different constitutional roles (eg the Greffe, Viscount, Attorney General, Police, private law firms, Probation, Prison). It may therefore be inappropriate for a computer system used by one of these agencies to be controlled by another of them. For example, it would be inappropriate for a computer system managed and controlled by the Police Service to be used to run the administration of the Courts. It is thus likely to be necessary, even in the long term, for these different bodies to retain separate computer systems under their own management.
Nevertheless, integration of processes between these agencies can still be achieved in this situation. This can be done by defining interfaces through which electronic information can be sent out of one system into another system, using predefined rules. The sending organisation has full control over the information sent, so there is no risk of inappropriate access to each other’s data. The receiving system can recognise and process the information received, provided it is in the agreed format.
Furthermore, if the receiving system is a Workflow system (as described in 3.5), it can automatically begin processing the information when it is received.
For example, a Magistrates Court system might transmit an electronic committal bundle to a system in the Law Officers’ Department, and the Police might also forwarded the Police File for the case electronically to the same system. If the Law Officers’ Department’s system was a Workflow system, when it had received both files for the same case, it might begin by automatically making certain checks, and then bring both files to the attention of the Attorney General’s Chief Clerk in order to nominate a suitable Crown Officer for the case … and continue in the same vein.
This method requires definitions of identifiers (see 3.4.4) and data standards, as well as rules within the receiving system to decide what process to follow when a new file is received. The recommendations in 3.4.3 and 3.4.4 relate to this.
There are a large number of places where electronic transmission of case-related information from one computer system into another would be beneficial. The detailed information model in Appendix G, and the high-level model given in figures 1 and 2 in section 2.3, show the many links between processes and organisations, many of which have potential for being "joined up" electronically.
Several of the areas discussed in sections 4.1 and 4.2 are specific instances.
Examples of potential for sending information between a Workflow system and other systems are included in the examples in section 3.6.
Figure 5 illustrates information systems in the States Police, Law Officers’ Department and Viscount’s Department each actively exchanging information with a central Court system, across defined interfaces.
In order to enable the communication between different organisations’ systems described above, it is recommended that:
· JLIB should promote dialogue between the organisations through the information sharing forum LINK (as recommended in 5.1);
· each organisation which is running, developing or proposing a system (such as those listed in 5.1) should be responsible for agreeing proactively with each partner organisation, for each piece of information to be transferred between their systems, the format of the data and the details of how it will be transferred;
· JLIB should take responsibility for setting the standards and overall methods to be followed, particularly when information exchanges are planned between multiple systems (eg for criminal cases or civil actions
Further recommendations appear in section 5.1.
To achieve interfaces between different case-handling systems, also required would be an identifier for each case, recognised and used by all the systems involved.
Currently each organisation’s system appears to use a different type of code to identify cases. Appendix D lists codes discovered during the interviews. Some of these apply to entities other than cases (eg pieces of legislation, or property contracts), but the following systems all use their own codes relating to cases:
· the States Police Crime Information System (CIS);
· the Probation Service’s ICMS system (based on person rather than case);
· the Law Officers’ Department’s Dataease document tracking system;
· the Judicial Greffe’s Pending List file (for Civil Actions being defended);
· the Judicial Greffe’s Sine Die file (for Civil Actions adjourned indefinitely);
· the Judicial Greffe’s reference number on an Act of Court;
· the Judicial Greffe’s reference codes for Unreported Judgements;
· the Viscount’s Department’s Court Enforcement System.
(Details of these codes can be found in Appendix D.)
It is not suggested that all these could be totally replaced by a single Case ID, as some of them may serve additional purposes and so in some instances might need to remain in parallel with a single Case ID, but:
It is recommended that plans are made towards creating a unified Case ID, acceptable to all parties, ultimately to be referenced by all parties, to enable the long term goal of "end to end" case handling to be achieved.
The Probation Service in particular mentioned that a common ID with the Police service and the Prosecution service would be a benefit to them.
The Prison Service were considering obtaining the same system as the Probation Service (ICMS), but did not anticipate using the same Person ID (CRN) as the Probation Service (i.e. the same person would have a different ID in each system). If the Prison Service do obtain the ICMS system, it is recommended that this question of common Person ID with Probation be re-examined.
As well as the three levels of information exchange defined above, it is helpful to distinguish between two different degrees of automation within computer systems, referred to for the purposes of this report as:
· "conventional systems" (less automation); and
· "Workflow systems" (more automation).
A conventional computer system can allow the electronic creation, storage, processing and transmission of documents, but under the control of the user. A user normally, as a minimum, "presses a button" to initiate processing or other activity by the computer.
A Workflow system, in contrast, schedules activities according to defined rules and timescales, so that when a user has completed one task, the system is able for example:
· to pass the case automatically to another user whose input is next required; or
· to wait until a scheduled date/time before presenting the case to the next user for action; or
· to transmit information about the case to another computer system, if interfaces have been defined (as discussed in 3.4).
Workflow is the automated application of rules which will route a document according to its content. The process could start with a document being received automatically from another computer system: rules programmed within the Workflow system could know what to do with it and where to send it, depending on the precise contents of the document.
A brief example (based on the Law Officers’ Department) is given towards the end of section 3.4.1. A fuller example (based on the Royal Court) is described in section 3.6.1.
Section 3.6 discusses opportunities for Workflow systems.
When different agencies have Workflow systems linked together by interfaces as described in 3.4, the highest level of integration can be achieved. This can bring into reality the goal of "end to end" case handling. This enables active exchange of information between systems (the exchange being automatically generated by one system and acted on by the receiving system), as opposed to passive exchange (where information is sent on the user’s initiative, eg by email or floppy disk, and is fed into the receiving system by the user at that end).
It is recommended that the ideal way to achieve "end to end" case handling is for organisations to adopt Workflow systems (as described in 3.5) with automatic interfaces (as described in 3.4), to allow information on cases to flow automatically across systems, prompting human action when it is needed.
This could start at the processes Provide Police Services, Represent, or Initiate Civil Action, and end at the processes Implement Sentence, Provide Prison and Probation Services, or Implement Civil Judgement.
An example of a benefit would be for part of the system to be able to audit whether and when a sentence had been served so that a criminal case could be considered fully "finished".
It is recommended that a Workflow system be considered to handle (initially) Civil Actions and Criminal Cases in the Royal Court and Jersey Court of Appeal, including Interlocutory Summonses. This would include the facility for lawyers to submit documents electronically. This could form a central building-block towards future "end to end" case handling.
Such a system could cover relevant functions of the Samedi Section, Family Section, Appellate Section and Interlocutory Services within the Judicial Greffe, and the Court booking and planning functions of the Bailiff’s Chambers.
A Workflow system centred on the work of the Royal Court (and the Jersey Court of Appeal) could give significant benefits. To achieve these, interfaces would be required with other organisations’ systems, even if they were not Workflow systems themselves.
The following suggestions indicate the type of approach which could be possible. Examples of some key points are given, rather than a full description of a proposed system. (Areas such as Interlocutory Summonses, Remands, Sentences, Civil Judgements and Costs would be included although not mentioned below.)
An electronic "cover sheet" is envisaged, containing basic details about a case, which would be passed to different parties when they were being prompted to carry out some action concerning the case. The system would construct the "cover sheet" automatically on behalf of the Greffe when one of the following was received:
· a Billet/Summons;
· an Order of Justice/cover sheet;
· an Indictment;
· or a requirement to book a Court date for Sentencing or Trial if this was indicated prior to receipt of an Indictment.
(For the first two cases, see 8.1 re the issue of Treasury Stamps.)
Various procedures, checks, messages and diary entries would be generated thereafter, either automatically or following human activity which had been prompted by the system.
Parties to the case would submit further electronic documents and files, quoting a reference supplied by the system, and these would become "attached" to the cover sheet and readable by those entitled to view them. However, these attachments would remain in "folders" allocated to each party (each Advocate and Crown Advocate), to maintain the current position that the Greffe is not responsible for the contents of these folders (except in the case of Criminal Appeals to the Jersey Court of Appeal).
Dates provisionally booked by the Bailiff’s Secretary for future hearings in the Court Diary would be marked as "provisional"; when they were confirmed in a Friday sitting, this would be entered (as part of the Greffe’s recording activity), and the system should link it to the case and change the booking to "firm" in the Court Diary. If for any reason a different date had been specified in Court, the system would flag this up to the Bailiff’s Secretary and those concerned.
When parties to a Civil action come to arrange a date with the Bailiff’s Secretary, the system would confirm to him that the Greffe had indeed ordered the case to be set down - this loop may not be closed at present - and the Bailiff’s Secretary would at the same time be shown the Greffe’s summary of the case if one existed. In more general terms, the system would ensure that no step was carried out before any necessary pre-conditions had been met.
Nearer the date of a Civil hearing, the parties could be automatically prompted (eg by email) and asked to confirm that the hearing was still expected to be needed (notwithstanding that the Bailiff’s Secretary may in some cases also need to keep in touch by telephone to remain appraised of the latest situation regarding any possibility of an out of Court settlement).
The parties (in both Civil and Criminal cases) could also be automatically reminded by the system of deadlines for submission of bundles, or other approaching deadlines.
This should have the benefit of allowing Civil appeals to the Jersey Court of Appeal to be undertaken in a shorter timescale than at present (when it can take up to a year). It is understood that the present timescales were laid down based on the technology available in 1964; the Court of Appeal (Jersey) Law is currently under review to change this.
Further than the automatic reminders suggested in 3.6.1, if Advocates had suitable systems, a Royal Court workflow system could send entries into Advocates’ diaries confirming dates of hearings, deadlines for submission of bundles or other documents, and possibly a warning so many days or weeks prior to a deadline.
Similar principles to those described for the Royal Court in 3.6.1 could apply to the lower courts, although the emphasis would be different as the number of cases is far greater and the complexity generally less. Nevertheless a criminal case can undergo various types of remand for different reasons, leading to the accused being presented to the Magistrates Court up to four times for a given case. (This study has not examined whether the COURAS system implements Workflow principles to any extent.)
A Workflow system (similar in nature but not content to what has been described in 3.6.1) would also be valuable to cover the activity of the States Police. The Police Administrative Support Unit (ASU) has produced a detailed flowchart of information flows which gives an indication of the complexity involved.
It is recommended that the desirability of Workflow principles, together with the principles listed in 3.4.3 and 5.1, be taken into account in the Police’s Case Preparation System project.
Information flows within the States Police, in preparing files both for the Magistrates/Youth Court and to pass to the Law Officers’ Department for prosecution in the Royal Court, and to a number of other organisations such as Honorary Police, Defence Advocates, Probation Service and Analysts, could significantly benefit.