two way interface business process - data.police.uk way interface - business... · issue error!...

1

Two Way Interface – Business Process

Version: 1.0

Publication Date: 06/07/2012

Description: The process and approach for sharing case information between policing and the Crown Prosecution Service.

Author: Chris James

For more information regarding this standard, please contact:

[email protected]

© Crown copyright 2012

This information is licensed under the Open Government Licence v2.0. To view this licence, visit www.nationalarchives.gov.uk/doc/open-government-licence/version/2 or write to the Information Policy Team, The National Archives, Kew, Richmond, Surrey, TW9 4DU.

http://www.nationalarchives.gov.uk/doc/open-government-licence/version/2

http://www.nationalarchives.gov.uk/doc/open-government-licence/version/2

Issue Error! Unknown document property name.

Error! Unknown document property name.

Two Way Interface - Business Process - v1.0

1

Amendment History

Date Issue Status Author

28/07/2008-

09/05/2011

0.01 -

0.19

Drafts Simon Gay /

Chris James

06/07/2012 1.0 Issued definitive for changes

agreed in May and June 2012

workshops.

Chris James

Reviewers

Name Role

Author(s)

Chris James CMS Functional Design Authority

Bill Blackburn Compass Business Consultant

Janette Zeller CMS Business Analyst

Davinia Maharaj CMS Business Analyst

Reviewer(s)

Steve Walmsley CPS Design Authority

Rachel Gennery CPS BIS team

Lancashire Police

North Wales Police on

behalf of the other

Niche forces

Dyfed Powys Police

Greater Manchester

Police on behalf of West

Midlands Police

South Yorkshire Police

Distribution

All parties in the reviewers list

Compass Programme Document Library




2

Table Of Contents

1 Management Summary ........................................................................... 5

2 Introduction .............................................................................................. 6 2.1 Purpose .................................................................................................. 6 2.2 Background ........................................................................................... 6

2.3 Scope ..................................................................................................... 6 2.4 Summary ............................................................................................... 6 2.5 Issues ..................................................................................................... 8 2.6 Change Forecast .................................................................................... 8 2.7 References ............................................................................................. 9

2.8 Abbreviations ........................................................................................ 9

3 Business Context .................................................................................... 11 3.1 Background ......................................................................................... 11

3.2 Benefits ............................................................................................... 11 3.3 Systems Supported .............................................................................. 12 3.4 Pre Charge Business Flows and Processes Supporting Pre-charge .... 12

3.5 Post Charge Business Flows ............................................................... 21 3.6 Key Business Assumptions ................................................................. 24

4 Pre-Charge Business Message Model .................................................. 28 4.1 Business Flows .................................................................................... 28 4.2 Message Model Diagrams ................................................................... 44

4.3 Business Events................................................................................... 54

5 Post Charge Business Message Model ................................................. 57 5.1 Business Flows .................................................................................... 57 5.2 Message Model Diagram .................................................................... 69

5.3 Business Events................................................................................... 71

6 Logical Message Model ......................................................................... 73 6.1 Overview ............................................................................................. 73 6.2 General Message Rules ....................................................................... 75

6.3 LM01 - Initial Case Material .............................................................. 81 6.4 LM02 - New Defendant ...................................................................... 96 6.5 LM03 - Updated Defendant ................................................................ 98 6.6 LM04 - New Witness or Victim ....................................................... 101 6.7 WM01 - New Witness or Victim ...................................................... 106

6.8 LM04u - Updated Witness or Victim ............................................... 108 6.9 WM01u - Updated Witness or Victim .............................................. 113

6.10 LM05 - New Witness Statement ....................................................... 116 6.11 LM06 - New Exhibit ......................................................................... 120 6.12 LM07 - New Case Document ........................................................... 123 6.13 LM08 - Full File Sent Indication ...................................................... 126 6.14 DM01 - Updated Defendant .............................................................. 128

6.15 CM01: Pre-charge Decision Request ................................................ 131 6.16 CM02: Pre-charge Decision Response ............................................. 141 6.17 CM03: Charge Information ............................................................... 151

6.18 FM01 - Case Status ........................................................................... 154




3

6.19 FM02 - New Action Plan .................................................................. 158

6.20 FM03 - Split/Merge Synchronisation ............................................... 164 6.21 Business Responses .......................................................................... 166

7 Data Protection, Protective Marking and Security .......................... 174

8 Detailed Data Assumptions ................................................................. 177 8.1 Message Contents ............................................................................. 177 8.2 Data Dictionary ................................................................................. 181 8.3 Data ................................................................................................... 191

Appendix A Relationship to Manual of Guidance ................................................. 194 A.1 Pre-charge ......................................................................................... 194 A.2 Post Charge ....................................................................................... 195

Appendix B MG3 Forms .......................................................................................... 199 B.1 MG3 Page 1 Completed by the Police .............................................. 199 B.2 MG3 Page 2 Completed by the Duty Prosecutor.............................. 200 B.3 MG3A ............................................................................................... 201

Appendix C Charging Workflow ............................................................................ 202

Appendix D Generic Classification Model ............................................................. 203 D.1 Validation ......................................................................................... 205 D.2 CaseClassification............................................................................. 209

D.3 Person Classification ........................................................................ 212 D.4 DocumentClassification .................................................................... 217

D.5 ExhibitClassification......................................................................... 220

D.6 CaseOutlineHeading ......................................................................... 221

D.7 ParticularsClassification ................................................................... 222 D.8 CaseAnalysisHeading ....................................................................... 223 D.9 GeneralDecison................................................................................. 224 D.10 ReasonCode ...................................................................................... 225

D.11 AdjudicationDecision ....................................................................... 227 D.12 OrganisationClassification ................................................................ 228 D.13 Material Classification ...................................................................... 229 D.14 FileOptionClassification ................................................................... 230

Appendix E Police Consultation Matching ............................................................ 232

Appendix F Party Matching .................................................................................... 234

Appendix G Offence Matching ................................................................................ 236

Appendix H Message Ordering ................................................................................ 237 H.1 Introduction....................................................................................... 237 H.2 Timing Precedence in CMS .............................................................. 238 H.3 Timing Precedence in Police Systems .............................................. 239 H.4 Update Ordering ............................................................................... 239

H.5 Delete Versioning ............................................................................. 247

Appendix I Potential Changes ................................................................................ 249




4

I.1 Introduction ....................................................................................... 249

I.2 Catalogue .......................................................................................... 249




5

1 Management Summary

This document defines the police/CPS interface from a business perspective

in term of the business models and flows of information that are supported.

The interface involves the COMPASS Case Management System (CMS)

and associated Witness Management System (WMS) which share a common

database and a range of systems in place with local forces. These include the

NSPIS Custody and Case Preparation products, Niche RMS and a range of

local force systems. The interface is standardised, but can be used in various

ways to support local working practices.

This document covers the 2nd

version of the interface which provides for a

two-way interface. The 1st version of the interface continues to be supported,

thereby allowing forces flexibility in their implementation of changes.

The interface is built on a series of messages that allow information to be

sent from:

a) a police system to the CPS, principally to provide structured case

information and evidential material.

b) the CPS to a police system, allowing updates of information and in

particular support for the pre-charge decision phase of a case.

The benefits of the electronic interface are mainly around reduction in the

need to re-key information in different systems, thereby providing an

efficiency gain. The interface also provides an increased amount of

information electronically, thereby decreasing reliance on the physical/paper

file. Other benefits in terms of greater focus on common joined-up processes

and tackling data quality during deployment of the interface are considered

secondary benefits.




6

2 Introduction

2.1 Purpose

This document defines a generic business messaging model between police

systems and the COMPASS case management applications, CMS and

WMS. The interface can be used to pass initial case file and evidential

material, pre-charge information, witness/victim information and support

interaction between the police and the CPS to better manage the file building

process. The main benefit is to avoid the re-keying of information on police

systems and the COMPASS CMS.

CMS shares a common database with WMS and information provided

across the interface is thereby available to both CPS CMS users and

police/CPS WMS users.

The business message model will be used as input to the specification of

Compass CMS and police IT systems and forms part of the Interface project

documentation set.

2.2 Background

During 2004 a one-way interface from police systems to the CMS was

introduced. This has proved successful in terms of benefits, but it was

recognised early on that with the introduction of statutory charging, a two-

way flow of information was needed. This has since been emphasised

through the need to share information on witnesses as a result of

commitments to improve witness care.

The version 2 interface has therefore been defined to refine the existing

interface in view of changes to business requirements and introduce a flow

back from CMS to the police systems.

The original interface was developed based on the functionality within the

NSPIS Case Preparation system. Since 2004, other police systems have

adopted the interface with the result that nearly all police systems now have

pre-production or live interfaces with the CMS.

2.3 Scope

The message model defined in this document is version 2 of the CJS

Exchange interface, referred to as ExISS v2. The existing version 1 message

model, known as ExISS R1a will continue to be supported for those forces

not wishing to move to version 2.

2.4 Summary

This document consists of the following sections:

Business Context - identifies the business process flows which the

interface will serve to support and key business assumptions




7

surrounding the operation of the interface. A business process flow

here means a set of information that passes between CPS and the

Police and the real world events that cause the flow to occur. The

pre-charge flows are discussed in section 3.4 and the post-charge

ones in section 3.5.

Business Message Model - describes at a high level the messages

that will be used between the police and CPS systems and how they

will support the business process flows. The messages that support

the pre-charge flows are discussed in section 4 and the post-charge

ones in section 5.

Logical Message Model - provides a detailed definition of each

message along with constraints on the use of the message.

Security - covers the security and data protection requirements for

the interface.

Detailed Data Assumptions - contains further detailed assumptions

relating to some of the data items referenced in the logical message

model.

Appendix A - relates the XML interface to the Manual of Guidance

[MoG].

Appendix B - shows the current MG3 and MG3A forms in use

supporting the pre-charge process.

Appendix C - shows the pre-charge workflow as a flowchart for the

police and the CPS.

Appendix D - explains the generic classification structure being

introduced at version 2 of the interface.

Appendix E - explains the structure of a pre-charge consultation

created in CMS with usage notes for the Police on storing and

manipulating this in their IT systems.

Appendix F - explains the name matching rules required to ensure

that the Pre-charge aspects of this interface can work alongside the

other means of exchanging Pre-charge details between the Police and

CMS as would happen for example out of hours though CPSD.

These rules are also extensible to processing victims and witnesses

received on LM04 messages.

Appendix G - explains the offence matching rules required to ensure

that the Pre-charge aspects of this interface can work alongside the

other means of exchanging Pre-charge details between the Police and

CMS as would happen for example out of hours though CPSD.




8

Appendix H - explains the schemes by which CMS and police

systems decide on the order to process outstanding messages

received by them to ensure data integrity is maintained.

Appendix I – lists possible areas of further change that may benefit

digital working.

2.5 Issues

None yet identified.

2.6 Change Forecast

Version 0.12 of this document reflected the discussions in a series of police

workshops held in March and April 2009 to refine the interface ideas last

documented in September 2008 in version 0.11. These Spring 2009

workshops have led to clarifications in:

how the split/merge business model will work;

the content and relationship of the 3 CM* messages;

the structure and use of the post-charge FM* and WM* messages.

Version 0.13 built on this and reflected feedback from May 2009 CPS pre-

charge workshop, in particular refinements to the split/merge model that

better reflects the way CPS Duty Prosecutors work and a fuller description

of the individual messages in section 6. Version 0.14-0.16 provides further

clarification and refinement as a result of ongoing analysis by both CPS and

the Police, including police charging reconciliation.

Version 0.17 addressed comments from a detailed review of v0.16 by the

Police and CPS and is the version that the TWIF Project Board, under

recommendation for the TWIF Working Group, have signed off and

approved as the baseline against which the analysis of the changes to CMS

and the police IT systems can be completed.

Later versions up to v1.0 reflect minor changes and clarifications identified

as the three early adopter forces‟ TWIF systems were developed, tested and

taken into live operation.

Following sign off approval further amendments to the BPD are subject to

formal change control with the members of the Working Group forming the

change control board which will be chaired by George Flanagan of

Lancashire Constabulary.




9

2.7 References

Mnemonic Information Details

[PCDBPD] Title:

Reference No:

Issue No:

Date:

Marking:

Police/CPS PCD XML Interface - Business Process

Document

499030-0102

1.0

25th

November 2005

Not Protectively Marked

[BPD] Title:

Reference No:

Issue No:

Date:

Marking:

Police/CPS XML Interface - Business Process

Document

25501706

1.0

7th

April 2004

Not Protectively Marked

[IPS] Title:

Reference No:

Issue No:

Date:

Police/CPS XML Interface - Physical Specification

X009c

2.00 Definitive

14th

June 2004

[SCHEMA] Title:

Reference No:

Issue No:

Date:

Data Schema: Police - CPS Messages (The schema

files accompanying this [IPS])

X007a

V2-0

14th

June 2004

[IPS2] Title:

Reference No:

Issue No:

Date:

Police/CPS XML Interface Version 2 - Physical

Specification

Not yet issued

Not yet issued

Not yet issued

[SCHEMA2] Title:

Reference No:

Issue No:

Date:

Data Schema: Police - CPS Messages Version 2 (The

schema files accompanying this [IPS2])

Not yet issued

Not yet issued

Not yet issued

[GPMS] Title:

Reference No:

Issue No:

Date:

Government Protective Marking Scheme

n/a

See http://www.cabinetoffice.gov.uk/spf/sp2_pmac.aspx

4th

Dec 2009

2.8 Abbreviations

ASN Arrest Summons Number

CCR Contract Change Request

CJIT Criminal Justice IT

CJO Criminal Justice Organisation

CJSE Criminal Justice System Exchange

CJX Criminal Justice Extranet

CMS Case Management System

CPS Crown Prosecution Service

CPR Criminal Prosecution Reference

CRN Custody Reference Number

DR Disaster Recovery

ECHR European Convention for Human Rights

GPMS Government Protective Marking Scheme

http://www.cabinetoffice.gov.uk/spf/sp2_pmac.aspx




10

IBA Interchange and Benefits Agreement

MCA Magistrates‟ Court Act

MIS Management Information System (part of the CMS)

MoG Manual of Guidance

NFA No Further Action

PNC Police National Computer

POPO Prolific and Priority Offender

DYO Deter Young Offender

PTI URN Pre Trial Issues Unique Reference Number

ROTI Record of Taped Interview

W3C World Wide Web Consortium

YO Young Offender




11

3 Business Context

3.1 Background

The exchange of information between the police and the CPS is largely

defined by the Prosecution Team Manual of Guidance (MoG) that defines

the approach to building the prosecution file at pre-charge stage, initial

hearing and if the case proceeds further to evidential files. The paper process

assembles this information into a series of MG forms.

The electronic interface reflects the business processes laid out in the MoG

and provides a mechanism for transfer of structured information (e.g.

defendants and associated offences) and evidential material (e.g. typed

witness statements). The one-way flow of information from police to CPS

became a two-way interaction with the advent of the pre-charge decision

(PCD) process in 2004. At subsequent stages of the prosecution additional

information passes between police and CPS in both directions.

Version 2 of the interface extends the capabilities of the version 1 interface

[BPD] to additionally support a two-way flow of information.

The interface is not intended to replace the role of the paper file as the

master record at this time but is designed to support the business processes

already in place.

In time the CPS intends to work with CJ Partners to replace the Physical

Case File, of which the Paper File is a component, with an Electronic Case

File. The implementation of a Two Way Interface, described in this

document, is a necessary requirement to do so.

3.2 Benefits

A comprehensive analysis of benefits is to be contained in the Police and

CPS interface business cases1. In summary they include:

A reduction of re-keying information already entered in one system into

the other. This will also reduce the number of transcribing errors;

Pre-charge decisions will be returned to the police electronically;

The electronic material will be created earlier in the case lifecycle;

Enhanced support for WCUs by providing the ability to supply witness

information prior to charge;

1 The Two Interface Project Board resolved on 18th

August 2009 that the creation of a

composite business case was too demanding. The approved approach is for each party to

TWIF bears its own costs for development and implementation of the TWIF. Each party to

deal its own internal governance arrangements for costs and benefits.




12

Improved sharing of information across the CJS, leading to less reliance

on the paper file.

3.3 Systems Supported

There are currently a number of police IT systems in use around England

and Wales. The CPS has a single national system, CMS. Running alongside

CMS is WMS, used by police/CPS witness care units. The interface will

provide a generic form of communication between CMS/WMS and the

existing police IT systems. The systems that currently are candidates to

partake in this interface are:

System Name User Provider

Compass CMS CPS Logica

NSPIS Custody and CasePrep Police Sungard

NicheRMS Police Niche Technologies

Consortium Force Systems Police Various

Logica and the CPS have agreed that Compass CMS will be modified to

support version 2 of the interface with a possible deployment date of Q3

2010. This document does not place a timescale on when other police forces

should be modified to use version 2. It is envisaged that it may take a

number of years from the point where the first police force transitions to

using v2 of the interface to the point where all forces, or even the majority

of them, do so. During this transition period v1 of the interface will remain

fully supported for use by those forces not wishing to use v2.

3.4 Pre Charge Business Flows and Processes Supporting Pre-charge

This section defines the business process flows between the police and CPS

that occur as part of the pre charge process and that are within the scope of

this interface.

3.4.1 Overview

The paper processes uses two MG forms, the MG3 for first consultation and

the MG3A for any subsequent consultations. The PCD process requires that

the MG3 and MG3A are completed in two stages. The first stage provides

information relating to the case and is completed by the police; the second

stage that the CPS completes details the pre-charge decision. The first stage

is a “request” from the police to the CPS for a pre-charge decision using the

case information supplied in the MG3. The second stage is a “response”

from the CPS to the police containing the pre-charge decision based upon

the information supplied by the police in the request.

The police may ask for a pre-charge decision at a number of points during

the investigation. These points, as enumerated on the MG3, are:




13

Pre arrest;

Post arrest;

Post interview;

Post bail for further enquiries;

Bail for charging decision.

Once the police send in a pre-charge decision request they typically follow it

up with a discussion with the Duty Prosecutor although the emerging

charging model in 2009 allows for a more disconnected mode of working in

which consultation requests may be dealt with by CPS lawyers without

direct discussion. If a discussion occurs it may take place in one of four

ways (as enumerated by the MG3):

Face to Face;

Written;

Using CPS Direct.

Using CPS Daytime Direct

The outcome of the Duty Prosecutor‟s assessment is a decision to prosecute,

issue a non-prosecution disposal code (e.g. caution), take no further action

or request further information.

If the decision is to request further information then an MG3A is sent in, by

the police to the CPS, for a pre-charge decision rather than an MG3. The

MG3A is an addendum to the MG3 providing further details about the case;

it does not duplicate suspect information such as the name and address of

the suspect. This means that a suspect can only appear on one MG3,

detailing their name and address, any further pre-charge decision requests

for the suspect must be submitted on a MG3A.

The Duty Prosecutor might decide that there is insufficient evidence for

there to be a realistic prospect of conviction and so issue a no further action

decision. In this instance the suspect is released from custody and the case

against the suspect is no longer pursued.

If the decision is to issue a non-prosecution disposal code then police

formally issue the reprimand, caution etc. to the suspect for the charges

specified by the Duty Prosecutor; release the suspect and update their

records.

Finally, the Duty Prosecutor may decide to charge the suspect. In this

instance a hearing is booked for the suspect and they are either bailed to

appear at the first hearing or retained in police custody. Information relating

to the charges and the next hearing are then sent to the CPS and to the

relevant Magistrates‟ Court.




14

3.4.2 Business Flows

This section lists the information that passes between the CPS and the Police

during a pre-charge decision.

3.4.2.1 Pre-charge decision request

To make a pre-charge decision request the police supply the following

information:

the case reference number (PTI URN) (this is mandatory);

suspect details (mandatory);

proposed charge details for the suspect (optional in the pre-TWIF

business process but will be mandatory in the post-TWIF process - see

section 4.1.2.4 for more details);

the officer seeking the decision and their supervising officer

(mandatory);

a list of material provided to the CPS e.g. a reference to a witness

statement (optional) (the actual material may be presented by the police

officer or sent in using the existing police/CPS interface after this

message has been sent in);

an outline of circumstances and decision sought - this may be given

verbally rather than on paper (mandatory);

a flag indicating previous convictions, final warning etc (optional);

the officer completing the MG3 form (mandatory).

An optional indication of any preference for how police-CPS contact

during the consultation should be conducted, taken from „face-to-face‟,

„written‟, „telephone‟ or „electronic‟ – the latter implying that no direct

contact is necessary.

The version 2 interface will remove the need to re-key case information that

is existing in the police IT systems into Compass CMS. It will also present

information that aids the Duty Prosecutor in making the pre-charge decision.

Note: The early legal advice aspect of this business flow will not be

supported in the version 2 interface in the way it currently is in version 1. In

version 1 suspects could be omitted from an early legal advice request but in

version 2 such requests (indeed all forms of pre-charge request) must always

be sought from the CPS in the context of a named suspect who has an Arrest

Summons Number. Where the police do not yet have a named suspect the

convention under version 2 will be to provide a dummy suspect name and

dummy ASN which will be used to send and receive advice via the interface

messages. The CMS system has to physically create these dummy suspects




15

but it is entirely at the discretion of the police systems whether they do so as

well. In using the version 2 interface like this it is recommended, though not

mandated, that police forces adopt a common convention for the dummy

name and dummy ASN which will be determined during the implementation

phase.

3.4.2.2 Pre-charge decision response

The pre-charge decision response will result in one of four outcomes:

a decision to prosecute;

a decision to issue a non-prosecution disposal code e.g. caution;

a decision to take no further action;

an agreement with police to undertake further investigation with an

expectation that a subsequent consultation will take place.

If a decision to prosecute is given the pre-charge decision response will

include the charges the CPS Duty Prosecutor wants the police to put to the

suspect. These charges may optionally include the full offence wording (the

particulars of the charge) based on standard PNLD templates if these have

been authored by the Duty Prosecutor. However the TWIF business process

does not mandate the circumstances when this would happen. The extent to

which the Duty Prosecutor provides the offence wording for various classes

of charges as part of the pre-charge consultations for is dependent on local

arrangements between each CPS area and its associated force and these are

outside the scope of this specification.

This decision for the suspect along with a discussion of the decision, an

action plan (potentially recommending the splitting of the pre-charge case

along with other ancillary actions), reconciliation of police proposed charges

with those advised by the duty prosecutor and those advised charges are then

recorded and handed over to the police.

The version 2 interface between CPS and the police will reduce the need to

re-key the pre-charge decision into the police IT systems once it has been

entered into CMS.

3.4.2.3 Charge

Once the police charge a suspect (who on charge becomes a defendant) they

inform the CPS of the following information:

the defence solicitor representing the suspect (optional);

the next hearing information for the suspect (mandatory);

the arrest summons number for the suspect. This would be the same as

originally provided by the police to the CPS when the pre-charge request




16

was made unless the police have updated the ASN in the meantime2.

Either way, the ASN provided here would be that currently held against

the defendant. (mandatory.);

the criminal prosecution reference (CPR) for all offences. Note: this is

held in CMS for future integration with Libra but not otherwise used for

TWIF. Part of the CPR will be formed from the related defendant‟s ASN

but the TWIF business process does not check these are consistent with

one another. The police may update the defendant ASN at any time and

it is their responsibility to ensure that the CPR associated with an

offence sent to CMS is the same CPR as sent to Libra for that offence.

(mandatory);

the arrest summons sequential number for the offences (optional);

the URN of the case under which the charges are to be brought

(mandatory);

the charge information for the defendant e.g. CJS offence code

(mandatory);

the full wording of the charge put to the defendant (mandatory).

Further case papers may be sent through to the case.

The version 2 interface will remove the need for the CPS to re-key this

information into CMS once it has been entered into the police IT system.

Note : The information on this „Charge‟ business flow may also be sent to

CMS in cases involving minor offences where the police charge a suspect at

the outset without first requesting a pre-charge decision from the CPS. This

would be via an LM01 message, as described in 5.1.1, as opposed to a

CM03 message when CPS have previously provided a pre-charge decision.

3.4.2.4 Summary of Business Flows

The interface will support the following business flows:

a pre-charge decision request from the police to the CPS;

a pre-charge decision response from the CPS to the police, including

structured charges, not free text, if the decision is to charge; The

structured charge data returned will include PNLD codes, offence dates,

optional offence wording (the offence particulars) and adjudication of

original police proposed charges as described under police charging

reconciliation in section 4.1.2.4.

2 A change to the ASN at the pre-charge stage would be communicated to CMS via an

LM03 message, see section 6.5.




17

a charge information message from the police to CPS containing the

actual charge laid and next hearing information.

Under the interface the pre-charge request and response business flows do

not have to be synchronised which means in multi-handed cases the police

may make multiple pre-charge decision requests which could be matched in

turn by a single pre-charge decision response containing decisions for all

suspects or by multiple pre-charge decision responses containing decisions

for different suspects. This would depend on when the CPS Duty Prosecutor

chooses to action one or more outstanding pre-charge decision requests on a

case.

3.4.3 Business Processes

This section lists the events that happen in a case at the pre-charge stage that

causes the business flows listed in section 3.4.2 to be exchanged.

3.4.3.1 Police investigation

The police may decide to consult with the CPS at a number of points during

the investigation and custody phase.

Ahead of a PCD request the police review the evidence, then if appropriate

and subject to supervisor authorisation consult the CPS. The police may

charge a suspect without a CPS decision in cases authorised by the Director

of Public Prosecutions in guidance issued from time to time.

3.4.3.2 Pre-Charge Decision Request

Upon deciding that a consultation is required with the CPS the police must

collate the information required for the request and enter it into their IT

system. At this stage, the suspect is generally in custody or subject to police

bail. The information captured would typically include the suspect‟s details,

and reason why the suspect has been arrested, by reference to an offence. In

reviewing the case and preparing the information for submission to the CPS

police will suggest charges to the Duty Prosecutor based on the evidential

material and the criminality alleged not just the reasons for the arrest. These

proposed charges will be supplied with an outline of the case and references

to supporting evidential and other materials such as a witness statement,

ROTI and police report. This is then provided to the CPS as a request for a

pre-charge decision. The proposed charges may thus be different from the

reasons for arrest with the relationship between them private to the police

force. CPS only have sight of the proposed charges even though there may

be situations where they are no different from the reasons for arrest, not that

that would be know to the Duty Prosecutor during the consultation.

The supporting material (e.g. witness statements) may be presented to the

CPS through the ExISS interface or through other existing channels e.g. fax

or as a paper copy. At this stage the material is often handwritten.




18

3.4.3.3 Pre-Charge Consultation

The police officer seeking the decision discusses the case with the Duty

Prosecutor as part of a consultation. The officer provides an outline of the

circumstances relating to case and answers questions. The Duty Prosecutor,

using the information supplied by the police on the request and during the

discussion, makes a charging decision and, with the officer, agrees an action

plan.

The consultation takes place face to face or remotely, by telephone.

3.4.3.4 Pre-Charge Decision Response

The Duty Prosecutor records the decision, the analysis supporting the

decision, such as whether there is sufficient evidence and the case is in the

public interest, records for a prosecution decision (A, B or B2)3 or a

conditional caution decision (D), an adjudication decision for each of the

proposed charges provided on the Pre-Charge Decision Request and if

necessary an action plan with a review date(s). A record of the decision is

provided to the police as a pre-charge decision response.

In a pre-charge response, the Duty Prosecutor provides a single disposal

code (decision) for each suspect. This decision is at the level of the suspect

as a whole and in itself makes no explicit declaration about how the

individual charges originally proposed by the police were assessed during

the pre-charge consultation. However, depending on the suspect level

decision the pre-charge response will also contain varying detail about the

assessment of the original police proposed charges in order to help qualify

the suspect level decision as follows:

Suspect decision Response to police

proposed charges

Prosecute (A, B, B2)

Conditional caution (D)

Each charge

adjudicated

individually by the

Duty Prosecutor with

potentially different

responses.

No prosecution - evidential (K)

No prosecution - public interest (L)

No prosecution - conditional caution non compliance (D2)

TIC (G)

Each charge

adjudicated

automatically by CMS

with the same

common response

equal to the suspect

level decision.

All others (C, D5, E, F, H, I, J, M, Z) No charge adjudicated

and responded to.

3 As detailed on the MG3 and recorded within Compass CMS




19

Police systems use the information returned in the pre-charge response to

record in PNC the outcome of each of their original reasons for arrest. In

doing so they can use the adjudication value against the proposed charge if

provided, or infer the outcome from the suspect level decision if an

adjudication value isn‟t provided. In the latter case (inferring the outcome) a

police force may develop their IT system to do this automatically or may

decide it requires manual intervention by a police officer to decide on the

outcomes based on inspecting the suspect decisions and consultation

narrative returned in the pre-charge response. In either case, the business

process does not state how the PNC outcome should be set based on

information returned in the pre-charge response. The nature of the

adjudications given for each type of suspect decision is discussed further in

section 4.1.2.4.

3.4.3.5 Implementation of the Charging Decision

Upon receipt of the charging decision from the Duty Prosecutor the police

may take one of a number of different actions.

If the decision was to take no further action then the suspect is informed.

The case is finalised and no further action is taken against the suspect.

If the decision was to investigate the matter further and resubmit then the

suspect may be bailed pending further enquires. The further information is

gathered and the pre-charge process repeated.

If the Duty Prosecutor decides that the suspect should be cautioned then this

is issued and the case is finalised. Should the suspect reject the caution then

a further pre-charge decision request will be made to the Duty Prosecutor

who will reactivate the case and conduct a consultation.

The Duty Prosecutor may have decided to prosecute. In this situation the

suspect is charged. A first hearing is booked, which is generally the next

available hearing date, in accordance with agreed local practice. The

defendant is either bailed to appear at court or retained in police custody.

This information is then collated together and provided to the CPS for the

first hearing.

3.4.3.6 Preparation for Prosecution

The CPS prepare for the first hearing and the prosecution phase of the case

begins.

3.4.4 Pre-Charge Splitting and Merging

As part of the pre-charge decision response the Duty Prosecutor considers

how the case should proceed and there are three basic options:

1. Split. Parts of the case under consultation should be managed under one

or more separate URNs. Variants include:




20

i. In a multi-handed case, one or more suspects for whom further

pre-charge investigation is required are moved to one or more

separate new cases.

ii. In a multi-handed case, one or more suspects should be charged

and all their offences prosecuted under one or more separate new

cases.

iii. In a single handed cases a suspect should be charged and some of

the offences prosecuted under one or more new cases and some of

the offences prosecuted under the original case.

iv. Variation of iii) in which on a multi-hander some, but not all,

offences for some suspects are moved to once or more new cases.

2. Merge. The case under consideration should be merged in its entirety

with another existing case and wholly managed under the single URN of

the post-merged case. Variants include:

i. Separate suspects on different cases being merged into a single

case and a consultation then performed on that merged case.

ii. The same suspect on different cases being merged into a single

case and a consultation then performed on that merged case.

3. No-change. The case under consideration should be managed in its

entirety under its existing URN regardless of whether it is a single

hander or a multi-hander with a mix of NFA, further information or

prosecution decisions.

In the split scenarios the Duty Prosecutor will complete the consultation on

the case and the instructions to split it then returned to the police as part of

the action plan for that consultation. The police would then create the new

cases as necessary using URNs of their choice and move suspects/offences

around as necessary; this is termed a “pre-charge split”.

In the merge scenarios the Duty Prosecutor will first merge the required

cases, which causes a merge instruction to be send on its own to the police,

and then perform a single consultation on the merged case which when sent

back to the police would not contain any further merge instructions. A

merge may typically be identified by the Duty Prosecutor when the police

ask for two or more pre-charge cases to be assessed at the same time by the

same Duty Prosecutor. Alternatively, the Duty Prosecutor may decide to

merge the case for which a consultation has been requested with another

existing case for which a consultation has already been performed.

At present most police systems supporting the v1 interface provide limited

or no support to split and merge cases which has a further implication on the

manual processes followed after case registration, on both CMS and police

IT systems, in that care is needed to ensure that the CPS and police are

referring to the same cases, which may now be organised differently on their

respective systems.




21

However for police systems operating with version 2 of the interface it is

recommended that they be able to split and merge their cases in the same

way that CMS does in order that messages can be sent in both directions

between those post split/merge cases. At the least this requires that:

For a pre-charge split police systems can create a case with a new URN

and move to it some of the defendants, offences, witnesses etc from an

existing case.

For a pre-charge merge police systems can move all case data from an

existing URN onto another existing URN.

The version 2 interface doesn‟t demand that police systems can split and

merge cases in the way CMS does, though for those systems that can‟t, only

a reduced set of messages can flow between the split and merged cases. This

is explained in more detail in sections 4.1.4.3 and 5.1.5.1.

3.5 Post Charge Business Flows

This section identifies the key business flows between the police and the

CPS which this interface aims to support.

3.5.1 Initial Case Information

The typical scenario following the charge of a defendant by the police is that

an initial case file is prepared and sent to the CPS. Depending on the

specifics of the case, typically the bail or custody status of a defendant, this

file may be sent to the CPS office or it may be handed over to the CPS

prosecutor just prior to the first hearing.

If initial case file information for a case that has not involved pre-charge

decision is sent via the interface then it must be the first information

received by the CPS for a case using this interface. Entry of this data into the

CMS will be automatic.

3.5.2 Full Case Information

If the case proceeds to trial in the magistrates‟ or Crown Court or committed

for sentence then the CPS request that the police prepare an Evidential File

or a Committal File. (for the purposes of this document a Committal File is

taken to include a file prepared for Committal for Trial, Sending, Transfer,

Voluntary Bill of Indictment, or any other means by which a case moves

from the Magistrates Court to the Crown Court, except an appeal or

Committal for Sentence)

The evidential or committal file is prepared in accordance with the Manual

of Guidance and typically contains:

Witness details - name, age, gender, ethnicity, contact details etc;

Witness Statement details - statement number, date of statement etc;




22

Exhibit details - reference number, producer, type, location.

The interface supports the transfer of structured information and evidential

material such as statements and ROTIs thereby removing the need to re-key

this information in to the Compass CMS when it is provided by the police.

Additionally the interface will support the exchange of the typed witness

statements and exhibit documents (e.g. ROTI). The interface will support a

mechanism to allow the police to send other documents for attaching to the

CPS case with some restrictions. Post charge, this interface will not support

the exchange of scanned images (including still photos), videos or audio

material which may form part of the case file. Submission of scanned

images at the pre-charge stage is supported. Note: The rules for exactly

when in a case‟s lifecycle, particularly those involving multi-handers,

scanned material sent from the police to CMS is deemed to be “post-charge”

and will be rejected are still under discussion but will be reflected in a later

release of this document via a receipt rule in section 6.12.4.

3.5.3 Provision of Further Information

It is normal business practice for the police to send the CPS further pieces of

information as they become available. This might arise for example if a

further defendant is arrested or a new witness, witness statement or exhibit

is available.

Additionally either party may wish to inform the other that some

information has changed for example a witness may now be at a new

address or no longer even required on the case.

In each case this will result in one party re-keying this further or revised

information into their IT system. It is the aim of this version 2 interface to

remove the need to re-key as much of this information as possible, and it

will support the addition of new information to a case as well as the

amendment of some existing information. Where revised information is not

supported through the interface this will continue to be handled using the

current paper based business process.

Once the initial case information has been received by the CPS then the CPS

are responsible for any amendments to the charges. This interface will

therefore not support the receipt of new charge details for a defendant within

a case unless they are with respect to a new defendant. New or amended

charges will continue to be handled using the current paper based business

process. The exception is the unlikely situation where, on the same case, a

charged defendant is subject to a further pre-charge consultation for new

offences in which further charges are recommended as part of the

prosecution.4 The interface would support submission of these charges in the

4 Note : The addition of further charges as described here is intended to include the

situation in which a defendant has been charged and remanded into police custody by a

magistrates court to enable further enquiries to be made. However if a defendant is re-

arrested after initial charge and the police do so under a separate arrest event, the defendant




23

same way as the ones initially put to the defendant. Once the case is

progressing through the prosecution process the electronic case data in the

CPS system will be maintained by both witness care officers on behalf of

the witnesses and by lawyers and admin staff on behalf of the defendants

and to a lesser extent the witnesses as well.

It is normal business practice for CPS to inform the police in turn of updates

made to existing defendants and witnesses or the addition of new witnesses

which would require the police to re-key that information into their systems.

Again, the aim of the version 2 interface is to reduce the extent to which this

re-keying happens.

3.5.4 Case Status Updates

Once the prosecution phase of a case is underway CPS may ask the police to

amend the type of case file they are preparing, to either stop, start or modify

the file build in order that the correct effort is spent on building a case file

appropriate to the nature of the prosecution. This would typically happen

when a case goes to trial or moves from the Magistrates‟ Court to the Crown

Court, or if CPS get an indication of an early guilty plea before the first

hearing. These file build instructions are communicated to the police via a

general purpose CPS police memo although some areas have developed

specialised memo templates to better serve this purpose.

The CPS may finalise cases, reactivate cases and cases can be put under

appeal and the police need to know when these events occur in order to

know to stop work on the file build or be prepared for further work on the

case, potentially because there is outstanding confiscation work or one of its

suspects was the subject of an earlier conditional caution.

3.5.5 Case Splitting and Merging

A key business assumption listed in section 3.6 is that once initial case

information has been passed to CPS via the interface, the police will not

split or merge the case file unless instructed to do so by CMS. There is no

restriction on police splitting or merging files prior to the initial material for

the affected cases being sent.

The CPS, however, may decide to split or merge cases on Compass CMS at

any point between registration and finalisation. This has implications for the

way that CMS handles messages from the interface, in that when cases have

been manipulated in this way, CMS must ensure that messages from the

police are applied to the correct case. At present police systems do not

generally provide automated support to split and merge cases post-charge

and in the present one way version 1 interface this results in most messages

will have a new ASN and CPS would then expect the circumstances surrounding that

second arrest to be managed under a new URN including any further consultations. CPS

may decide to later merge the URNs if necessary.




24

received by CMS being applied to all split/merge cases descended from the

4 part URN in the inbound message.

Police forces operating with version 2 of the interface are recommended to

be able to split and merge their post-charge cases in the same way that CMS

does so that future exchanges of data between those split/merge cases can be

case specific and CMS and the police systems can refer to the cases in the

same way. Even then, the police will only split or merge a post-charge case

when instructed to do so by a version 2 CMS message. That said, the

business process does not demand that v2 police systems do implement

split/merge in the way CMS does. For those forces that don‟t, 2-way

message exchange will still be possible when CMS splits or merges a case

although some messages will no longer be able to be sent and other

messages will cause duplication of data across cases that the Police and CPS

will have to manually deal with. More details of this are given in sections

4.1.4.3 and 5.1.5.1.

3.6 Key Business Assumptions

The following assumptions have been made about the manual business

processes that will surround this interface:

1. The master file, where it exists and as prescribed by the Manual of

Guidance, will remain the physical/paper file. The electronic interface is

a step towards an electronic file.

2. All messages through the interface ( Pre-Charge Cases and Charge

Cases) will contain a PTI URN and continuity of the PTI URN is

essential. Once message exchange has begun between a police system

and CMS the URN cannot be edited on either side.

3. In all version 2 messages the „Split‟ element of the PTI URN will be

used to denote cases which have been split off from the original URN.

Police systems are recommended to be able to split cases in the same

way as CMS and if they do then the individual split cases can partake in

dedicated message exchange. If they can‟t the message exchange is more

limited as described in sections 4.1.4.3 and 5.1.5.1. However the police

choose to split, or not, cases on their system they must be able to manage

those cases in the real world in a manner compatible with their system‟s

split capability.

4. Support for unused material will remain a manual process, i.e. this

interface will not transmit a structured unused material schedule. The

existing business processes for receiving and updating the unused

material schedule will remain unchanged. The interface would allow the

police to send an unstructured document containing the unused material

schedule to the CPS as it would allow the sending of other documents

(see section 6.12). The structured list of witness statements and exhibits

that is transmitted over the interface will include only those that are

currently included on the MG9 and MG12 (see sections 6.10 and 6.11).




25

5. The interface is only intended to handle material protectively marked no

higher than Restricted. CMS, CJS Exchange, the police IT systems

connected via this interface and the network infrastructure are all

running at Restricted High.

6. Both the police and Compass CMS applications may support the

concepts of splitting and merging of case files. An assumption has been

made that once the initial case information has been passed to CPS via

the interface then no further splitting or merging of the case will take

place on the police system unless instructed to do so by CMS. The police

may split or merge a case at any point up until the first message is sent

across the interface for that case; after that point the police may only

split or merge a case at the request of the CPS.

7. Reconciling exhibit references in witness statements remains a manual

process.

8. Any messages received via the interface for a case that has been

finalised on CMS will, except under certain specific circumstances, be

rejected as described in section 4.3.3. Where these circumstances don‟t

hold a manual process will be required to reactivate a case on CMS if

there is a need to receive further information via the interface. This will

need to be done prior to the information being sent.

9. It will still be possible to register a case manually on the Compass CMS.

In this scenario CMS will not possess the unique identifiers for the case,

defendants, offences etc. The CMS will therefore not be able to match

up the manually registered information against information received via

the interface. The interface will not support the updating of initial case

information where the case has been manually registered on CMS

(although it will support provision and subsequent update of some new

initial case information - see LM02, CM01, LM04). The interface will

support receipt of full case information where the case has been

manually registered on CMS.

10. Only cases where the CPS is the prosecutor or a Pre-Charge Decision is

required from the CPS will be sent across this interface.

11. Requests for Early Legal Advice will no longer be supported by version

2 of the ExISS interface in the way they were supported under version 1.

Police forces wanting an exchange of information on early legal advice

cases with CMS will need to use the pre-charge CM01 message with a

dummy suspect and a dummy ASN. Forces are not obliged to create

these dummy suspects on their systems but must still use them in the

messages to exchange information with CMS. A suitable convention will

adopted through appropriate naming of the dummy suspect for forces to

be able to identify it as such on a message and handle it differently, as

required, from a real suspect.

12. The CJSE will receive business data from the police IT system or

Compass CMS and pass it directly to the recipient system. The CJSE




26

will not process the business data to be passed across this interface for

any other purpose.

13. Data for MCA cases will only be sent to the CPS using this interface if

the CPS is involved in the prosecution.

14. Summons cases that fail legal scrutiny will not be sent to the CPS using

this interface.

15. The police and CPS will be able to set suspect/defendant level

monitoring codes such as PPO, DYO, YO etc and various other aspects

of the suspect demographics like gender and surname. Both

organisations will be able to edit these in their systems and send the

updates back to the other.

16. Both the Police and the CPS will set the case level monitoring codes,

such as Child Abuse and inform each other of these. However the Police

can only set a restricted subset of all the available codes and would

typically only do so at the outset of a case or when adding a new suspect

to a case. The CPS will be able to override these monitoring codes at any

time within CMS and will always inform the police of any updated

codes via a return message. It is then at the discretion of police systems

if they choose to store or ignore that information from CMS.

17. It will still be possible to register and perform pre-charge decisions

manually on CMS. However, certain conditions must be met for these

cases to have messages sent for them, namely that their URNs are

associated with forces participating in version 2 messaging and that the

case on CMS has previously received a message from the police, i.e. that

the case is known to exist on the police system.

18. The police will not send the ExISS LM02 message for a defendant that

has been subject to a pre-charge decision. Details on such defendants

should be sent using the new CM01 and CM03 messages (see section

4.1).

19. The police will be able to generate URNs, ASNs and unique suspect

identifiers for those cases they intend to participate in the interface.

20. Pre-Charge Messages can be sent in for a case that the CPS has split on

CMS provided that the pre-charge message fully qualifies the URN via

the PTI URN split suffix element.

21. Scanned material can only be sent in support of a Pre-Charge

consultation. Evidential material provided post charge such as

statements and ROTIs will be sent as typed documents in MS Word or

Rich Text Format (RTF).

Note: As of June 2012 agreement has not been reached within the

Working Group as to exactly what stage in its prosecution lifecycle a

case should no longer accept an LM07 message with a non editable




27

document. As such CMS can continue to receive LM07s with any type

of attached document at any time.

22. Each police will deploy its v2 ExISS software throughout all its police

units in its geography at the same time, i.e. no force can operate a mixed

mode of v1 and v2 messaging.




28

4 Pre-Charge Business Message Model

This section takes the high level business flows identified in Section 3.4 and

defines a series of messages which support them. The messages are

described at a high level. Constraints, exceptions and other conditions can

be found in sections 6.15 to 6.17 where each logical message is covered in

detail.

4.1 Business Flows

4.1.1 Pre-charge Decision Request

The pre-charge decision request business flow can be represented by a

single message in the interface. The message will be called CM01: Pre-

charge Decision Request and will be used to support both initial (MG3) and

follow on (MG3A) consultations.

The receipt of this message will trigger a number of steps depending upon

certain criteria:

Automatic registration of a new case in CMS, providing a case with the

same URN does not already exist.

Addition of the suspects to the case. A suspect will only be added to the

case if it can be determined that they do not already exist on that case.

This is done by applying the rules set out in Appendix F but which

amount to checking if:

o the globally unique identifier for the suspect already exists on the

case);

o or, if not, a defendant suspect match can be identified based on

full name and date of birth5;

Update of existing suspects on the case if they are determined to be the

same as on the CM01. With some minor exceptions, namely Police

Remand Status, Bail Date and Bail Conditions, only those suspect details

which are not yet defined in CMS will be updated from the CM01. It is

expected that a CM01 would operate in an update mode where its

suspect already exists on a case because either the case has been

registered manually on CMS via MG3 paperwork before the CM01 is

processed by CMS or because the CM01 is for a follow on consultation

request for an existing suspect. During the pre-charge stage though, if

5 It is accepted that name matching as described in Appendix F could produce unwanted

matches where father and son with the same name, for example, are added to the case file

without date of birth or middle names provided to distinguish them, or where same age

siblings are added without first names. These problems will be avoided by provision of

complete and accurate information at the outset otherwise manual clean up of the case data

may be necessary.




29

the police change suspect details these would be sent to CMS via an

LM03 message. Police systems and CMS can exchange updates of

suspect/defendant details at any time in the case lifecycle via LM03 and

DM01 messages, as discussed further in sections 5.1.2, 5.1.7, 6.5 and

6.14.

Addition of the pre-charge decision request information to the case.

Any number of CM01 messages may be sent at any time to a case. In CMS

each CM01 message may cause suspects to be added to (or updated on) the

case along with the addition of the police outline of the circumstances text.

For the same case, the police may submit multiple suspects on a single

CM01 or use multiple CM01s.

The receipt of a CM01 on CMS and/or independent contact from a police

officer will prompt a duty prosecutor to assess the case although there is

nothing to force this assessment to happen immediately. A duty prosecutor

may choose to perform multiple pre-charge consultations separately in

response to each individual CM01 received or do one single consultation to

cover all outstanding CM01 requests.

When performing a consultation on a case a duty prosecutor may optionally

inspect other cases that are related in some way to that case and might

influence its assessment. CMS will make the duty prosecutor aware of the

existence of such related cases at the start of the consultation based on three

separate tests:

1. A case on CMS has a suspect/defendant with the same PNC Id as any

suspect on the case where the consultation is being performed;

2. A case on CMS has a suspect/defendant with the same ASN as any

suspect on the case where the consultation is being performed;

3. A case on CMS has been explicitly linked by the police to the case

where the consultation is being performed via the Associated PTI-URN

field on the CM01.

In 1 and 2 above, CMS will automatically scan all suspects/defendants

across all its cases, live or finalised, looking for matches and thus enable the

previous or current criminal activity of the suspect(s) being consulted on to

be considered as well. Note: A match on ASN is only expected to happen

where a suspect has been arrested for multiple offences under the same

arrest event, but the police have chosen to manage each offence in that arrest

event under a separate URN and request, via CM01s, consultations on each

of them. More typically, a suspect arrested multiple times over a period of

time would have a different ASN for each such arrest. The business process

doesn‟t mandate how ASNs are managed by the police, it simply brings

identical occurrences of them across different cases, if they exist, to the duty

prosecutor‟s attention. It is expected though that matches would be more

likely on PNC Id for repeat offenders.




30

In 3 above, it is entirely at the police‟s discretion whether they wish to

explicitly link other cases to the one for which a pre-charge consultation has

been requested, and such other cases could be those that are finalised, those

whose prosecution is already underway or those that are themselves subject

to a pre-charge consultation.

In 1, 2 and 3 above it is entirely at the duty prosecutor‟s discretion whether

or not he decides to inspect the related cases when performing a consultation

and if he does, to what extent the information therein influences the

consultation.

4.1.2 Pre-charge Decision Response

The pre-charge decision response business flow may also be represented by

a single message in the interface. This message will be called the CM02:

Pre-charge Decision Response. It will be sent by the CPS to the police

following completion of a pre-charge consultation by a Duty Prosecutor. It

is important to understand that a CM02 will be sent not in direct response to

receipt of a CM01, but in response to a pre-charge consultation being

completed in CMS that could address one or many outstanding consultation

requests. Receipt of a CM01 is one reason why a Duty Prosecutor might

subsequently complete a consultation in CMS but this could also happen

because the duty prosecutor has been manually asked to do so via material

on a paper, emailed or faxed MG3.

Further, receipt of completed MG3 forms from CPSD or Daytime Direct

will automatically create completed consultations on CMS. If the suspects

on the MG3 already exist on CMS with a known ASN, because of prior

receipt of a CM01, then the creation of the completed consultation will send

a CM02 to the police at the same time. However, if the MG3 arrived first at

CMS and created the suspects without an ASN the CM02 will not be sent

immediately but will be sent when the suspects‟ ASNs on CMS are later

acquired, typically through receipt of the CM01.

4.1.2.1 Suspect Decisions

When a consultation is completed in CMS each suspect on the case would

have been reviewed in the context of the evidential material and police

outline of circumstances text held on the case. In a CMS multi-handed case

every time a pre-charge consultation is performed a decision must be given

for every suspect/defendant on the case and each of these would be provided

on the CM02. In reality though not every suspect/defendant may require

explicit consideration during the consultation because either:

1. They have already been the subject of an earlier conclusive pre-charge

decision;

2. They have already been the subject of an earlier pre-charge decision and

it is anticipated that the police will provide further material at a later

date.




31

3. They have yet to be given a decision but will be considered in a future

consultation.

For such suspects/defendants CMS allows the duty prosecutor to use the

pseudo decision of „not given for this suspect‟. Such decisions however are

never returned on the CM02 as the police have declared them to be of

limited use.

Further, regardless of their decision, suspects will only be returned on a

CM02 if they are known to the police system by virtue of them having an

ASN recorded in CMS. The ASN is set by the police and sent as part of the

CM01 or LM03 so if defendants are created on the case in CMS without an

ASN we would infer they are not yet known to the police. This prevents the

police receiving unsolicited CM02 data for defendants not held on their

system.

Note: The ASN is not editable in CMS. Where a suspect is created on CMS

without an ASN and has a consultation completed where a non „not given

for this suspect‟ decision was given, then the CM02 for that suspect will be

held back and only sent at the point in the future where the ASN is acquired

via receipt of a CM01 or LM03.

4.1.2.2 CM02 Timing

Until such time as the Electronic Case File replaces the Physical File under

version 2 of the interface the paper MG3 form is still expected to be

maintained as part of the paper file. There may be situations where the

CM02 message is delayed because of unavailability of the CJS Exchange or

CMS and the police would first be made aware of the Duty Prosecutor‟s

decision via the return paper MG3. If charges are manually entered onto the

police systems from the MG3, then those systems must be able to cope with

a subsequent delayed receipt of the CM02 and not create further duplicate

charges.

4.1.2.3 CM02 Receipt

Receipt of the message by the police will cause a number of consequential

actions. These actions depend upon the decision and action plan made by the

Duty Prosecutor. The decision and action plan consequences are:

Decision - No Further Action:

The police release the suspects from custody, or cancel their

requirement to answer bail at a later date.

The case is finalised on the police IT system and CMS if all the

suspects on the case have either a non-prosecution disposal code or a

no further action decision.

Decision - Non-prosecution Disposal Code:




32

The suspect is released from custody in accordance with the terms of

the non-prosecution disposal (e.g. simple caution, final warning etc.)

decided by the Duty Prosecutor.

The non prosecution disposal code is entered onto the police IT system

for the offences specified by the Duty Prosecutor.

The case is finalised on the police IT system and CMS if all suspects

on the case have either a non-prosecution disposal code or a no further

action decision.

Decision - Further Investigation Resubmit:

The police either bail the suspect to return at a later date, or keep them

in custody whilst further investigations are carried out.

A subsequent request is made to the Duty Prosecutor for a further pre-

charge decision detailing the further information. This would be done

using a further CM01 message.

Decision - Prosecute:

The police draft the charges and put them to the suspect.

The charges are entered onto the police IT system as specified by the

Duty Prosecutor, full particulars are added to them, a CPR and ASN

sequential number is generated for each offence and a hearing is

scheduled for the defendant.

The defendant is either bailed to appear at the next hearing or is

retained in custody.

Action - Split Case:

The action plan on the CM02 instructs the police to split the case by

creating a new URN to manage one or more of the suspects on the

original URN. In the split, a suspect and all his offences may be moved

from the original case (a suspect level split) to the new URN or a

suspect may be retained on the original case with some, but not all, of

his original offences and also copied to the new URN along with the

remainder of the offences (an offence level split). The original URN is

always retained and would still have suspects. The police would copy

any witness/exhibit data from the original URN to the new URN and

(logically) delete now redundant witnesses on the original URN as

necessary.

If the new URN has charged suspects they will be sent to CMS on an

LM01. If it requires further pre-charge analysis this will be done via a

follow on CM01 from the new URN‟s case.

Action - Merge Case:




33

The Duty Prosecutor may decide to merge two or more related cases

together and perform a single consultation on that merged case. In this

case, the instruction to the police to merge the cases will be sent out

first on an FM02 message and the consultation decision will eventually

follow on a CM02 message. Thus, unlike the split, the merge

instruction will not form part of the CM02 action plan and is not

directly part of the response as it is sent in the earlier FM02 message.

This is explained further in section 4.1.4.

Action - General:

The action plan on the CM02 instructs the police to carry out further

actions at the pre-charge stage that may cover a variety of evidential

and/or witness issues. This would typically happen where the decision

was „further investigation‟ or to charge.

4.1.2.4 Police Charging Reconciliation

Proposed Charges and Advised Charges

The police submit to CMS on a CM01 proposed charges for each suspect

with each one comprising:

A police generated Unique Id;

A CJS Code with matching description and offence category;

A date, or date range, for the offence;

A location of the offence comprising up to 8 address lines and a

postcode. (Note: see further background to the use of the location

information in the text following Figure 44)

These proposed charges are adjudicated on by the duty prosecutor as part of

the pre-charge consultation. The adjudication decisions are returned on the

CM02 and used by the police to record in PNC the result of the original

offences for which the suspect was arrested. For each proposed charge the

content of the adjudication decision returned on the CM02 always includes

the original police generated Unique Id and the adjudication decision itself.

For certain adjudication decisions further supporting data may also be

returned. The adjudication decisions depend on the suspect level decision

given and are described in the Prosecution Decision section onwards just

below, along with a description of where further supporting data is also

returned.

If a suspect level prosecution decision is made by the duty prosecutor then

advised charges will be added against the suspect up in CMS. These may be

based on the proposed charges or may be different from them. Either way,

the adjudication decisions on the proposed charges are separate from the

advised charges and should not be confused with one another. The CM02

returns data separately on them both, although this section 4.1.2.4 is




34

primarily concerned with discussing the adjudication decisions on the

proposed charges.

When the duty prosecutor completes the consultation he will manually give

a single adjudication decision for each proposed charge provided on the

CM01 when the suspect decision is one of the following A, B, B2 and D.

The CMS system will automatically generate an adjudication decision for

each proposed charge provided on the CM01 when the suspect decision is

one of the following D2, K, L and G. Otherwise for C, D5, E, F, H, I, J, M

and Z decisions, no adjudication decision would be provided in the CM02

against the suspect‟s proposed charges.

The full set of values that are permissible for an adjudication decision are

dependent on the decision specified by the duty prosecutor for the suspect in

the PCD Consultation and are as follows:

Prosecution Decision

If the decision specified by the Duty Prosecutor for the suspect in the PCD

Consultation is A, B or B2 then one of the following adjudication decisions

must be specified for each of the suspect‟s proposed charges in the PCD

Consultation and distributed with the proposed offence in the CM02:

Accept: The duty prosecutor agrees fully with the proposed charge

details, therefore the following will be distributed in the CM02:

o An advised charge with the same PNLD code, police generated

Unique Id and exact same date(s) and location details as the

proposed charge.

Accept with Variation: The duty prosecutor agrees with the proposed

charge PNLD code but has varied the date(s) and/or location details

provided with the proposed charge, therefore the following will be

distributed in the CM02:

o An advised charge with the same PNLD code and police

generated Unique Id as the proposed charge. The date(s) and/or

location details of the advised charge offence will incorporate the

amendments made by the duty prosecutor

Replace: The duty prosecutor disagrees with the PNLD code of the

proposed offence and wishes to replace a single proposed offence with a

single replacement offence, therefore the following will be distributed in

the CM02:

o A new advised replacement offence with a different PNLD code

and a CMS generated Unique Id. The date(s) and/or location

details of the offence will be as defined by the duty prosecutor.

The new advised replacement offence will be linked back to the

proposed charge so the police know what offence their proposed

charge has been replaced with.




35

Reject: The duty prosecutor disagrees with the proposed charge PNLD

code and will not generate a replacement offence. There are no

associated charge details to be distributed in the CM02 for the proposed

charge. However the adjudication decision will be qualified with a

reason for the rejection which can take one of the following values:

o Evidential;

o Public Interest;

o Covered By Other Charges.

Taken into Consideration: The duty prosecutor has deemed the

proposed charge to be subsumed into another charge and this proposed

offence will not be taken any further. There are no associated charge

details to be distributed in the CM02 for the proposed charge

Caution: The duty prosecutor has deemed a simple caution is the

appropriate response to the proposed charge. There are no associated

charge details to be distributed in the CM02 for the proposed charge.

Further Enquiries: The duty prosecutor has decided the suspect should

be charged but is as yet undecided about the scope of this particular

proposed charge which is to be subject to further investigation even

whilst the suspect‟s charging under other offences gets underway.

The business process does not describe the circumstances under which a

duty prosecutor would adjudicate over each proposed charge - this is very

dependent on the circumstances of the case and the robustness of the

proposed charges. However, „further enquiries‟, „replace‟ and „reject‟ merit

further description because their usage is less self evident than the other

decisions.

Replace is envisaged to be used where the duty prosecutor decides that a

single proposed charge should be ignored and a single alternative charge

used instead to support the prosecution.

Reject is more complex and has a number of variants:

1. The proposed charge has no place in the pending charges set.

2. There is not a one-to-one relationship, e.g. police may propose a charge

on the right lines but doesn‟t cover the required offences. (handling

replacing 3 thefts) thus 1 theft replaced and the other 2 rejected.

3. May reject outright and charge something different in character.

Further enquiries is envisaged to be used where it is not yet known if the

defendant will or won‟t eventually be charged with the proposed charge, but

the suspect‟s prosecution should otherwise proceed immediately on other

more certain charges. On receipt of this code, the police should not result the

charge in PNC and instead wait until further dialogue has established its




36

fate. Not all CPS area would necessarily perform further consultations in

this situation. If they do then the fate of the proposed charge can be settled

via another CM01/CM02 loop; if they don‟t then the police will need to

manually declare the proposed charge‟s adjudication outcome in their

system based on their knowledge of what happens in the real world and at

that point they can then result it in PCN. Regardless of whether there is or

isn‟t a subsequent CM02 if a „further enquiries‟ proposed charge is

eventually added to the suspect‟s charge sheet then the police should still

send a CM03 to CMS.

When a set of proposed charges exist that will not form part of the advised

charge set, it is at the duty prosecutor‟s discretion whether these are not

taken forward via a mixture of reject and replace adjudications. In particular

where there is not a one-to-one relationship between the proposed charges

and the advised ones, it is envisaged that the rejection reason of „covered by

other charges‟ would be used more commonly than „evidential‟ or „public

interest‟.

Note: where a suspect level prosecution decision is given the duty

prosecutor may add advised charges against the suspect in CMS that are

unrelated to the proposed charges. These will be included in the

OffenceDecision element of the CM02 (see section 6.16.7) and include a

CMS generated Unique id; CJS Code, descriptions and category; date or

date range; optional location - present only if entered by the duty prosecutor.

Conditional Caution Decision

If the decision specified by the duty prosecutor for the suspect in the PCD

Consultation is D then one of the following adjudication decisions must be

specified by the duty prosecutor for each of the suspect‟s proposed charges

and distributed with the proposed offence in the CM02.

Accept implies the proposed offence is subject to this conditional

caution hence breaches of this CC should refer to this offence.

Reject implies the proposed offence is not subject to this conditional

caution hence breaches of this CC should not refer to this offence. The

adjudication decision will also be qualified with a reason for the

rejection which can take one of the following values:

o Evidential;

o Public Interest;

o Covered By Other Charges.

Replace implies the proposed offence is replaced by another. A

replacement CJS code, location and from/to dates will also be provided

in the CM02 for a replace adjudication decision for a conditional caution

suspect decision.




37

Further Enquiries implies the duty prosecutor is undecided whether the

proposed offence is subject to this conditional caution and is subject to

further investigation whilst the suspect is otherwise conditionally

cautioned.

There are no associated advised charge details to be distributed in the CM02

for the proposed charges in this scenario because charges are not added to

the case in CMS for a conditional caution and the suspect does not proceed

to court. The offences for which the suspect should be cautioned are those of

the proposed charge returned on the CM02 with an adjudication decision of

Accept or Replace. In the former case the date and location originally

supplied by the police remain valid and aren‟t returned in the CM02 and in

the latter case the date and location are set by the CPS duty prosecutor and

explicitly returned in the CM02 as part of the revised proposed charge.

Note: Where a conditional caution decision has been given, the CM02 will

also contain a list of the specific conditions and end dates that formed part of

that caution. These are not strictly related to the proposed charges and so are

not discussed further here, but that section of the CM02 is described in

section 6.16.7.

Taken into Consideration, No Prosecution - Evidential, No Prosecution -

Public Interest and CC Non Compliance - No Prosecution Decisions

If the decision specified by the duty prosecutor for the suspect in the PCD

Consultation is K, L, G or D2 then one of the following adjudication

decisions must be specified for each of the suspect‟s proposed charges in the

CM02 depending on the suspect decision (this will be automated by CMS

i.e. the duty prosecutor will not be required to specify these decisions)

No Prosecution - Evidential: The duty prosecutor has given a K

Decision for the suspect in the PCD Consultation, therefore an

adjudication decision of „No Prosecution - Evidential‟ will be distributed

in the CM02 for each of the suspect‟s proposed offences.

No Prosecution - Public Interest: The duty prosecutor has given an L


adjudication decision of „No Prosecution - Public Interest‟ will be

distributed in the CM02 for each of the suspect‟s proposed offences.

Taken Into Consideration: The duty prosecutor has given an G


adjudication decision of „Taken Into Consideration‟ will be distributed

in the CM02 for each of the suspect‟s proposed offences.

CC Non Compliance - No Prosecution: The duty prosecutor has given

an D2 Decision for the suspect in the PCD Consultation, therefore an

adjudication decision of „CC Non Compliance - No Prosecution‟ will be

distributed in the CM02 for each of the suspect‟s proposed offences.




38

There are no associated advised charge details to be distributed in the CM02

for the proposed charges in this scenario.

4.1.3 Charge Information

Having decided to prosecute the suspect the business message flow

transferring the offence information and the hearing details to CMS may be

modelled as a single message. This message will be called CM03: Charge

Information.

This message is sent once a suspect has been charged and the next hearing

and offence details, as specified in 4.1.2, have been entered into the police

IT system.

The receipt of this message indicates the start of the charge proceedings in

the Magistrates‟ Court and causes a number of events to occur:

The hearing details are added into CMS;

The offence information is updated with the CPR and ASN

sequential number.

4.1.3.1 CPS charge reconciliation

During the pre-charge consultation where a decision to prosecute the suspect

is given the duty prosecutor will add one or more pending charges for the

suspect in CMS. Some of these pending charges may be based on the

proposed charges originally sent in the CM01 and some of them may be

added by duty prosecutor independently of the proposed charges. In the

former case the pending charges will have the Unique Ids originally

assigned by the police and in the latter they will have Unique Ids generated

by CMS. Either way, the pending charges with their Unique Ids are returned

to the police on the CM02.

The Police must adhere to the Duty Prosecutor‟s decision and create in their

systems the charges on the CM02 advised by the duty prosecutor preserving

their associated Unique Ids. Proposed charges for which an „Accepted‟ or

„Accepted with Variation‟ adjudication decision was provided on the CM02

will already exist on the police system with police generated Unique Ids. If

the police create further charges of their own in accordance with the

Directors Guidance, then the police will assign Unique Ids for these. Either

way, all the charges entered onto the police system and put to the defendant

on the MG4 will be returned to CMS on the CM03 with their Unique Ids.

When the CM03 is received by CMS the presence of the Unique Ids serves

three purposes:

It allows CMS to match the return charges from the police with those

already on the case so an existing draft charge on CMS added via a pre-

charge consultation can be updated with details on the CM03, rather than

the CM03 creating a duplicate of those existing charges. In particular

this update will include the ASN sequential number allowing future




39

reference of the charge between CMS, Libra and the Police to be made

in a consistent manner.

Where a CM03 charge contains a Unique Id not recognised by CMS it

means the charge was added by the police in addition to those

recommended by the CPS.

If charges on CMS remain unmatched after a CM03 has been processed,

i.e. have not been updated with an ASN Sequence number, it means the

pending charges have possibly been ignored by the police.

Either of the last 2 scenarios above can be flagged to the prosecutor in CMS

for further manual investigation with the police as to why the discrepancy

exists.

The business process does not demand that the police delay charging the

suspect until the CM02 is received. Where the CM02 is delayed they may

proceed with charging based on information from a paper MG3 if available

and send the CM03 then. If this happens the lack of a full ordered exchange

of charge Unique Ids via the CM01 and CM02 means it is likely the police

and CMS will have created the charges under different ids and discrepancies

will inevitably be flagged in CMS for manual investigation when the CM03

is received.

The penultimate scenario above may also arise if the police subsequently

charge a suspect with an offence originally adjudicated as „further enquiries‟

but no subsequent consultation was performed or thus CM02 sent.

4.1.4 Supporting Split and Merge Pre-Charge

Merge

The Duty Prosecutor may become aware that separate cases he has been

asked to perform a pre-charge consultation on should be managed under a

single URN. In this situation the Duty Prosecutor will first merge the cases

in CMS and then perform a single consultation on the merged case. This

single consultation would cover the outstanding pre-charge requests on the

original unmerged cases. This leads to the following sequence of events

which affect the ongoing exchange of messages between the cases on either

side.

4.1.4.1 CPS merges

In this situation CPS has merged URNs A and B into URN A. At the point

of the merge CMS will send an FM02 message to URN A on the police

system as below.




40

A

Police CPS

A

B

FM02

The FM02 is discussed further in section 6.19 and is used to inform the

police of actions they need to perform on a case. In this instance it informs

the police they are to merge case A and B retaining A as the lead URN. The

message is sent only to the lead URN and would list all other URNs

(potentially more than just one other) that are to be merged with it.

Individual police forces can partake in v2 messaging in one of 2 modes,

either blocked or unblocked. In the blocked mode once CMS has sent the

FM02, any further messages produced from case A on CMS are not sent but

held back in a queue, i.e.

A

Police CPS

A

B

Message 1

Message 3

Message 2

X

In the unblocked mode once CMS has sent the FM02, any further messages

produced from case A on CMS are sent to both the original police A and B

cases. A copy of Message 1 would be sent to each of case A and B, identical

to one another except the URNs in each message would be A and B

respectively, i.e.

A

Police CPS

A

B

Message 1

Message 2

Message 3

Regardless of whether the police operate in the blocked or unblocked mode

whilst the merge remains unactioned on their system any messages sent

from their A or B cases will be processed against the merged case A on

CMS, i.e.




41

A

Police CPS

A

B B

When CMS receives a message for case B it internally routes it on to be

processed against case A because it knows that the information referred to in

the message from B will now be on its merged case A.

4.1.4.2 Police merge

Now the police merge their cases A and B into A and in doing so send an

FM03 to CMS. The FM03 is discussed further in section 6.20 and is used to

help synchronise split/merge activities pre- and post-charge. In this instance

it tells CMS that the police have completed the merge, i.e.

A

Police CPS

AFM03

If the police are operating in the blocked mode receipt of the FM03 causes

any messages held on CMS to be immediately released and sent en-masse to

the matching case A on the police side.

A

Police CPS

A

Message 1

Message 2

Message 3

If the police are operating in the unblocked mode receipt of the FM03

causes CMS to no longer send messages out to the original unmerged cases.

Regardless of the mode, once the FM03 has been received by CMS any

future messages from case A on CMS only go to case A on the police

system. Similarly, once the FM03 has been sent the police would only send

messages from their merged case A, i.e.

A

Police CPS

A

Any messages sent (in error, by definition) from the old police pre-merge

case B would now be rejected by CMS.




42

4.1.4.3 Block/Unblock choice

This 2-way business process does not mandate the extent to which police

forces need to be able to split and merge cases in the manner CMS does

which is why the police have the choice of the blocking mode they wish to

use based on their capabilities of their 2-way interface systems.

If a police system can automatically act on the FM02 to merge cases it is

recommended they operate in the blocked mode. Here, messages are only

sent between the police and CMS when the cases on each system are

organised in the same way as one another and there would not be any length

of time where this wasn‟t the situation.

If police systems choose not to split and merge cases as per CMS, which is

typical of the v1 systems, then they should operate in the unblocked mode.

Here, all messages from the merged CMS case will be sent to the unmerged

cases on the police system. This will invariably lead to the creation of data

on some of the cases that is not relevant or even potentially misleading and

it will be down to the force to resolve this locally themselves. Also some

messages might be rejected because they refer to data that doesn‟t exist on

the particular unmerged case.

A police system may still choose to split and merge as per CMS but may not

be able to do this automatically on receipt of an FM02. It may be a manual

process that could happen hours or days after the FM02 instruction. It is then

their choice whether to operate in the:

Unblocked mode where messages will still be received all the while from

CMS but whose data may require cleaning up when the cases are

eventually merged.

Blocked mode where CMS messages from the merged cases will only be

applied when the merge is completed on the CMS, avoiding any issues

of cleaning up data but at the expense of receiving no data until the

merge has completed.

In particular, a force that operates in the blocked mode but without

automated actioning of the FM02 merge message will not receive the CM02

consultation response from CMS until they complete the merge themselves.

Split

The pre-charge split process is slightly simpler. When completing a

consultation if a Duty Prosecutor decides that the case with URN A should

be split then the CM02 will be returned with an action plan stating which

suspects/offences should be retained on the original URN and which ones

should be moved onto one or more new URNs. It is then the responsibility

of the police to generate a new case(s) with a new URN(s) to hold the

suspects/offences split off from A. This leads to the events described below.




43

4.1.4.4 Neither side split

In this situation CPS have instructed the police to split case A into two

cases. CPS are passive here, unlike the merge, and are driven by what the

police do. Whilst the police take no action all messages can still be freely

exchanged between the police and CPS for URN A because that case

remains organised in the same way on each system.

A

Police CPS

A

4.1.4.5 Police initiate split

Now, the police create the second case and choose to assign it URN B.

A

Police CPS

A

B

Messages, perhaps further pre-charge consultations and responses, can still

be exchanged for case A. In the meanwhile the police will add defendants,

charges, witnesses etc as necessary to case B.

4.1.4.6 Police complete split

When the police finish assembling case B in response to the CPS directive

to split the original case A they then send details of it to CMS on an LM01 if

it is to be charged or a CM01 if it is to undergo further pre-charge

consultations.

A

Police CPS

A

B BCM01 or LM01

Messages may now be freely exchanged between URNs A and B. The

CM01 or LM01 that creates case B on CMS will use the

AssociatedPTI-URN to link it back to the original case A. This will support

the internal process in CMS that will tidy up any extraneous

suspects/offences that no longer belong on CMS Case A because they have

been moved to Case B instead.




44

The mode, blocked or unblocked, that the police operate in has no effect on

the pre-charge split process.

4.1.4.7 Managing Victims and Witnesses

When the police initiate a pre-charge split a new case is created and some of

the victims and witnesses from the original case may need to be created on

the new case if they are relevant there. In doing so, those individuals may

become redundant on the original case.

When the police match CPS‟s instruction to perform a merge at the pre-

charge stage it is possible that the same victim or witness had been present

on both original cases that became merged which would lead to duplicate

instances of them existing on the merged case, albeit with different Unique

Ids values.

In both situations it is desirable to purge the split and merged cases of any

unwanted or duplicated witnesses that may have arisen because of the split

merge process. The recommended business process is that whilst the case

remains in the pre-charge phase it is the police who take responsibility for

this. Such victims and witnesses would be removed from police systems

which would send LM04u messages (see sections 5.1.2 and 0) to CMS

causing a matching removal to be made there as well.

4.2 Message Model Diagrams

The diagrams in this section show the message model. Section 6 of this

document provides a detailed definition of the data that these messages

transmit and the constraints upon their use.

4.2.1 A Simple Pre-charge Decision Scenario

This scenario shows a simple pre-charge decision case where a suspect is

arrested, the police decide that there is enough evidence to suggest that the

suspect is guilty of the offence and send a CM01 to request a pre-charge

decision.

The Duty Prosecutor assesses the evidence gathered and decides that there is

sufficient information to proceed; they specify the charges and send the

response to the police as a CM02.

Upon receiving the Duty Prosecutor‟s decision the police draft the charges

and put them to the suspect; they book a first hearing before sending the

charge information back to the CPS as a CM03 and the case proceeds.




45

Police CPS

Police prepare case

material for a case with

one suspect.

Submit a pre-charge

decision request

Case registered on CMS

Suspect added to case

Pre-charge decision request

created for suspect

CM01: Pre-charge Decision Request

Police officer and duty

prosecutor discuss case and

make a decision. The duty

prosecutor specifies the

charges and outlines an action

plan.

Pre-charge decision sent to

the Police.Police receive the decision

and draft the charges.

CM02: Pre-charge Decision Response

Police charge the subject;

book the next hearing and

generate offence

information e.g. CPR and

update their IT system

Suspect is bailed to

appear at the next

hearing.

Charge information is sent

to CPS

Next hearing is recorded in

CMS.

Details of the offence put to

the suspect (e.g. CJS Offence

Code) and offence information

(e.g. CPR) are recorded

against the offences.

CM03: Charge Information

Case proceeds as an ordinary

charge case.

Figure 1 - A Simple Pre-charge Decision Scenario




46

4.2.2 A Pre-charge Decision Scenario Requiring Further Investigation

This scenario shows what happens when the Duty Prosecutor decides that

there is not enough supporting evidence to make a pre-charge decision and

requests further investigation.

In this situation the police have arrested a suspect and have decided there is

enough information to request a pre-charge decision using a CM01.

The Duty Prosecutor feels that with some more information he could make a

more informed decision and sends the response, in the form of a CM02,

back to the police asking for further investigation and submits an action

plan.

The police perform the further investigation, as prescribed, and submit a

further request for a pre-charge decision (CM01).

Following an assessment of the further information supplied by the police,

the Duty Prosecutor decides that there is sufficient information to proceed;

they specify the charges and send the response to the police as a CM02.




47

Police CPS

Police prepare case


one suspect.

Submit a pre-charge

decision request




created for suspect




decide further investigation is

required. An action plan is

drawn up.


the Police.

The police carry out the

further investigation and

enter it onto their system.


Police charge the subject;

book the next hearing and

generate offence

information e.g. CPR and

update their IT system

Suspect is bailed to

appear at the next

hearing.


to CPS


CMS.




(e.g. CPR) are recorded.



charge case.

Submit a further pre-

charge decision request

A second pre-charge decision

request created for suspect




make a decision. The duty

prosecutor specifies the

charges and outlines an action

plan.


the Police.

Police receive the decision

and draft the charges


Figure 2 - A Pre-charge Decision Scenario Requiring Further

Investigation




48

4.2.3 Splitting The Suspects On A Case Into Two Or More Cases

This scenario shows the processes that occur when the Duty Prosecutor

decides that two suspects on a case should not be charged together.

In this situation the police have arrested two suspects that are believed to be

associated. They have enough evidence to indicate that the suspects should

be charged and send a pre-charge decision request (CM01) to the Duty

Prosecutor.

Upon reviewing the pre-charge decision request and reviewing the case with

the police officer it is decided that the suspects should be charged

separately. The Duty Prosecutor enters the information into Compass CMS

and sends a CM02, pre-charge decision response, to the police.

The police, on receiving the pre-charge decision response, move one of the

suspects from the case onto a new case along with any witnesses as

necessary. Note: The extent to which this must be done manually or is

supported automatically would be based on agreements between the forces

and their IT system suppliers regarding the provision of functionality under

the version 2 interface.

The police draft the charges and charge both suspects. The charge

information is sent to the CPS as a separate CM03 message for the suspect

remaining under the original URN and the other as an LM01 message under

the new URN.

The LM01 will record as its Associated PTI-URN the original URN. This

will assist the business process in CMS of transferring the defendant and his

consultation from the original URN to the new URN.

Witnesses moved to the new case are sent to CMS for the new URN via

LM04 messages and witnesses removed from the original case are sent to

CMS for the original URN via LM04u messages.




49

Police CPSPolice prepare case


two suspects.

Submit a pre-charge

decision request


Suspects added to case


created for suspects




decide that the two suspects

should be charged separately


the police.


One suspect is moved

from the original case to a

new case with a new

URN.

Police draft the charges

and charge both suspects

on their respective cases.

Offence information such

as the CPR is generated

and hearings are booked

for both suspects.


to CPS for the suspect on

the original case.


CMS.







charge case.

Police receive the

decision.


to CPS for the suspect on

the new case.

A new case is registered for

the new URN, as a direct

result of the content of the

LM01. History from original

case is not automatically

carried over. Case is

associated with original case.


CMS.





LM01: Charge Information


charge case.

Witnesses on the case are

deleted

Witnesses on the original

case are removed and

CMS notified.

LM04u: Witness Update Information

Witnesses from the

original case are moved to

the new case and CMS

notified.

Witnesses on the case are

added

LM04: New Witness Information

Within CMS suspect is

manually removed from

original case and his

consultation copied to the new

case.

Figure 3 - A Pre-charge Decision Scenario Requiring the Case to Be

Split




50

4.2.4 Merging The Suspects On Two Cases Into One Case.


decides that a suspect with offences on three separate cases should be

charged together on the same case.

In this situation the police have arrested a suspect once in connection with

three separate offences that occurred at different times over a few days. The

police have chosen to manage each offence on a separate URN (A,B,C) and

three CM01 messages are submitted to CMS.

The Duty Prosecutor is made aware by CMS that the three cases are

associated with one another because their defendants have the same ASN

and in reviewing the material from all 3 cases decides that two of the

offences should be merged under one URN (A and B under A) and the 3rd

offence continue to be prosecuted under its original URN (C).

The Duty Prosecutor performs the A+B→A merge which sends an FM02 to

the police case A and then completes the pre-charge consultations on cases

A and C. In this example we assume the police operate in the blocked mode

and the timing is such that the Duty Prosecutor completes the consultations

immediately after the merge and soon after this the merge is completed on

the police system. The CM02 for the merged case would be delayed slightly

and then released when the merge confirmation FM03 is received which lifts

the block.




51

Police CPSPolice prepare case

material for 3 cases with

the same suspects but

different offences and

suggested charges.

Submit a pre-charge

decision request

for each case

Cases registered on CMS

Same suspect and different

suggested charges added to

each case


created for each case

3 * CM01: Pre-charge Decision Requests


prosecutor discuss all three

cases and decide that two of

the offences should be

charged together and the third

still charged separately.

Consultations performed for

cases A and C and pre-charge

decision sent to the police for

each case.


sent to case C. CM02 for case A retained

in CMS.

The merge instruction on

the CM02 for URN A is

actioned and it is merged

with URN B which sends

the FM03 to CMS

notifying it of the

completed merge.

Police draft the charges

and charge the suspect

twice on URN A. Offence

information such as the

CPR is generated and

hearings are booked for

all offences.

Next hearings and put

charges recorded against

case C which proceeds as

an ordinary charge case.

Next hearings and put charge

recorded against case C

which proceeds as an ordinary

charge case.

Police receive the

decision.

Outbound message block

released for merged case A.

FM03 : Split/Merge completion

CM03 : Charges for URN A

CM03 : Charge for URN C

Duty prosecutor merges A and

B into A and leaves C as it is.

Merged case A is now

outbound blocked

FM02 sent to A instructing

It to be merged with B

Police receive the merge

instruction

Police draft the charge

and charge the suspect

once on URN C. Offence

information such as the

CPR is generated and a

hearing is booked for the

offence.

Queued CM02 now released

for A


sent to case APolice receive the

decision.

Figure 4 - A Pre-charge Decision Scenario Requiring Cases to be Merged

Variations

In the example above if the police operate in the unblocked mode then when

the Duty Prosecutor completes the consultation for case A the CM02 is sent

immediately to the unmerged police cases A and B - assuming they are still

unmerged.

The police may then act in one of two slightly different ways:




52

Variation 1

When pending charges have been added via the CM02 full particulars may

be added at that stage, the CM03s returned to CMS and then the cases

merged. Even though CMS will receive a CM03 from case A and B their

charge data all ends up on the merged CMS case A.

Variation 2

When pending charges have been added via the CM02 the cases may be

merged and then full particulars added at that stage and a single CM03

returned to CMS and received against merged case A with all the charge

data.

It is not important to CMS which of these variations is chosen by a police

force and its IT system. CMS will manage the variations in such a way that

the end result on CMS will be the same as far as the police are concerned.

4.2.5 Composite Consultation


performs a single consultation on behalf of multiple suspects on separate

CM01s.

In this situation the police arrest a suspect and submit his details to CMS on

a CM01. The case is registered in CMS and a Duty Prosecutor notified that a

consultation is outstanding. No one is immediately available to deal with the

request and in the meantime the police arrest another suspect on the case and

submit his details to CMS on a second CM01 under the same URN.

The second suspect is added to the existing case which now has two sets of

case outline text held against it. A Duty Prosecutor becomes available and

completes a single consultation for both suspects. One CM02 is sent back to

the police with an NFA for one suspect and a charge decision for the other.

The police charge the defendant and send the details to CMS on a CM03.




53

Police CPS

Police prepare case


one suspect.

Submit a pre-charge

decision request




created for suspect.


No Duty Prosecutor available.

Decision request left

outstanding.

Duty Prosecutor available and

consultation performed for

both suspects on the one

case. Charging decision for

both sent to the police.


Police charge the

suspects, book hearings

and generate offence

information.



case.

Case proceeds as ordinary

charge case.

Police receive the

decisions and draft the

charges.

CM03 : Charge information for both suspects

Police arrest second

suspect and prepare case

material.

Submit a pre-charge

decision request for

second suspect on same

case as original suspect.

Suspect added to existing

case




Charge information sent to

CPS

4.2.6 „Not Given for This Suspect‟ Consultation


performs consultations at different times on a case as more suspects are

added to the case.

The police arrest suspect A and charge him with a motoring offence and use

an LM01 to register the case on CMS. Later they arrest suspect B on the

same case and submit a CM01 for him to CMS. The Duty Prosecutor

completes a consultation with an NFA. The return CM02 has the NFA for

suspect B and no details at all for defendant A who was given a code X (not

given for this suspect) decision during the consultation.

Later still, suspect C is arrested on the same case and a CM01 sent in for

him. The Duty Prosecutor decides to charge him with a code A and suspects

A and B are given a code X. On the CM02 suspect C is included with his

code A; suspect A and B are excluded because they were given a code X

during the consultation.




54

Police CPS

Police arrest suspect A

and charge with a

motoring offence.

Charge information for the

suspect sent to CPS.

Case registered on CMS and

next hearing recorded. Details

of the offence put to the

suspect also captured.

LM01: Charge Infornation

Duty Prosecutor completes

consultation for both suspects

on the one case. ‘Reprimand’

given for suspect B and ‘not

given for this suspect’ for

suspect A.


Suspect A excluded from the message

Police arrest third suspect

C, prepare case and

submit a pre-charge

decision request on the

same case as before.



case.

Case proceeds as ordinary

charge case.

Police receive the

decision. There are no

charges to draft and no

CM03 to send.

CM03 : Charge information for suspect C

Police arrest second

suspect B and prepare

case material.

Submit a pre-charge

decision request for

second suspect on same

case as original suspect.

Suspect B added to existing

case




Charge information sent to

CPS

Suspect C added to existing

case




Duty Prosecutor completes

consultation for all three

suspects on the case.

‘Charge’ given for suspect C

and ‘not given for this suspect’

for suspects A and B.


Suspects A and B excluded from the

message

Police receive the

decision and draft the

charges for suspect C.

4.3 Business Events

The logical message definitions in section 6 of this document reference a

number of business events as constraints. This section defines the business

events referenced in section 6.

4.3.1 Registration

Registration is the CPS business event of recording on the Compass CMS

that a new case has been received by the CPS.

There are four types of registration supported by CMS. The type of

registration performed will impact what further information may be received

over the interface.




55

Manual Registration - refers to the scenario in which the CMS user

chooses to create a new case on CMS and manually keys in the case

information. It will not be possible for police to tell if this has occurred

except through local business practice or waiting for an error response.

Email - refers to the scenario in which the police email a collection of

MG forms to CMS using the existing email interface. The standardised

MG1 if available, is parsed and information is extracted to pre-populate

the screens used for manual registration.

Full Electronic Registration - refers to the scenario in which the initial

case information sufficient to register the case is received electronically

through either the existing ExISS interface or this proposed interface.

CPSD/Daytime Direct MG3 registration - refers to the scenario in which

an electronic structured MG3 filled in by CPSD or Daytime Direct is

submitted to CMS which automatically parses the document and

registers the case without further user intervention. The case is registered

in CMS in the same way as if the data on the MG3 had been manually

entered into the CMS registration screens.

Any type of registration may be performed before or after the first hearing

for the case.

4.3.2 Split Cases

Splitting a case on Compass CMS occurs when it is decided by the CPS that

it is no longer correct to proceed with the case as it stands. The prosecuting

lawyer may decide that it is better, in a multi-handed case, to prosecute each

suspect under separate cases, in these circumstances the case is split into a

number of new cases. Similarly, the prosecuting lawyer may decide the

same for a number of offences being prosecuted under a single case for a

single suspect.

CMS will reject CM01, CM03, LM02 and LM08 messages received for

cases that have been split on CMS if the messages do not qualify the URN

with a split suffix as it will not be possible to determine which case split

from the original the incoming message should be assigned to. If a split

suffix is present then the message will be directed to the particular case split

from the original that the suffix identifies.

CMS will accept LM03, LM04, LM04u, LM05, LM06, LM07 and FM03

messages received for cases that have been split on CMS even without a

split suffix (meaning the police have yet to split themselves). These

messages will be applied to all the new case cases on CMS split from the

original.

4.3.3 Finalisation

A case becomes finalised on CMS when the prosecution activity is

concluded, no offences remain to be heard at any hearings and each




56

defendant has been assigned an outcome. Even after finalisation though, the

case may still be edited in CMS to manage certain non prosecution aspects,

typically related to communications and witness management. Case

finalisation is an important cut-off point that controls when certain messages

may still be received in CMS, though it is not the only factor in this. The

table below elaborates the CMS message receipt rules in detail.

Message CMS Receipt Rule

LM01 Case does not exist

LM02

LM03

LM08

CM03

Case is not finalised

LM04

LM04u

LM05

LM06

LM07

a) Case is not finalised OR

b) Case has

1. asset recovery work OR

2. conditional cautions for any

defendant

Note: b) allows messages to be received after

case finalisation provided the case is subject

to the stated activity.

CM01 a) Case is not finalised OR

b) Case has conditional cautions for any

suspect on the CM01

c) A new suspect would be added to the case

off the CM01

FM03 Case exists (in any state)

It is expected that the police will also have finalised their case at the point it

is finalised in CMS.

CMS supports the concept of case reactivation; this returns the case to a live

state and would allow all further messages to be received for the case from

the police. Case reactivation on CMS is usually a manual activity although it

will happen automatically if the conditions above are met and the LM07

contains an MG3 or MG3A document

As part of the version 2 interface the above reactivation criteria will still

hold but additionally receipt of a CM01 will also reactivate the case

provided the case has a defendant whose last pre-charge decision was a

conditional caution and the defendant exists in the CM01, or the case has a

defendant who has been finalised with a conditional caution and the

defendant exists in the CM01 or a new suspect needs to be added to the case

via the CM01.




57

5 Post Charge Business Message Model

This section takes the high level business flows identified in Section 3.5 and

defines a series of messages which support them. The messages are

described at a high level. Constraints, exceptions and other conditions can

be found in section 6 where each logical message is covered in detail.

5.1 Business Flows

5.1.1 Initial Case Information

The initial case information business flow can be represented by a single

message in the interface. The message will be called LM01: Initial Case

Information.

The receipt of this message at the CPS will trigger automatic registration of

a new case assuming all of the conditions defined in Section 6.3 are met. A

manual step by the CPS admin team may be required at this point (for

example to trigger preparation of case file labels) but that will not have any

bearing on this interface and is an internal matter for the CPS.

This message will only be sent once for a case.

5.1.2 Further Case Information

Following the submission of the initial case material using an LM01, or

charge and hearing information using a CM03 the police will be supplying

case material and information in accordance with local business practice

recorded in an Interchange and Benefits Agreement (IBA). In readiness for a

first hearing this is likely to include,

Details of key and non-key witnesses.

Witness statements (as appropriate)

A ROTI or SDN

An MG5, or MG5 SP.

Details of a defendants convictions.

As a case progresses requests for information from the CPS will be

responded to by the provision of further case information supplied using this

interface.

The police may wish to send additions to the case information both before

and after they have signalled that they have prepared the full file. In the

current business process further information or corrections to existing

information will be provided by the police right up until the case is finalised

by the CPS.




58

The following messages have been defined to allow additions to the case

information to be notified by the police to CPS:

LM02: New Defendant - this will allow the police to inform the CPS

that an additional defendant has been added to the case.

LM04: New Witness/Victim - as described in 5.1.3.

LM05: New Witness Statement - as described in 5.1.3.

LM06: New Exhibit - as described in 5.1.3.

LM07: New Case Document - this will allow the police to provide the

CPS with documents that will be automatically attached to the case, an

example use of this message might be to supply a Case Summary

(MG5).

The following messages have been defined to allow updates to existing case

information to be notified by the police to CPS:

LM03: Updated Defendant - allows the police to send updates to an

existing defendant on the case to the CPS. Only the demographic and

personal aspects of the defendant can be updated, i.e. attributes like

name, contact details, nationality, date of birth etc. In particular new

charges or amended hearing schedules cannot be sent via this message.

The full set of defendant data will be sent in the message rather than just

those aspects of it that have changed.

LM04u: Updated Witness/Victim - allows the police to send updates to

an existing witness/victim on the case to the CPS. Such updates would

also include notifying CPS that a witness/victim has been deleted from a

case. The full set of witness/victim data will be sent in the message

rather than just those aspects of it that have changed.

During the course of the case‟s prosecution the CPS may wish to send

amendments to defendant and witness information to the police at any time.

The following messages have been defined to allow additions to the case

information to be notified by the CPS to the police:

WM01: New Witness/Victim - allows the CPS to send full details of a

new witness or victim for the case to the police.

The following messages have been defined to allow amendments to existing

case information to be notified by the CPS to the police:

WM01u: Updated Witness/Victim - allows the CPS to send updates to an

existing witness or victim on the case to the police as per the LM04u

description above.




59

DM01: Updated Defendant - allows the CPS to send updates to an

existing defendant on the case to the police as per the LM03 description

above

5.1.3 Full Case Information

For the purposes of this document Full File is taken to mean the information

that should be submitted to the CPS by the police for the purposes of,

A trial in the magistrate‟s court.

A committal for trial to the Crown Court.

An Indictable only case Sent to the Crown Court.

A case Transferred to the Crown Court

A Case Proceeding by way of Voluntary Bill Of Indictment

As may be described in the Manual of Guidance.

The full file may arrive at the CPS either as a single batch of information or

it may be drip fed over a period of time with the information being delivered

to the CPS as it becomes available.

The following messages have been defined to support the delivery of the full

case information:

LM04: New Witness/Victim - allows the police to send full details of a

new witness or victim for the case to the CPS.

LM05: New Witness Statement - allows the police to send details of a

new witness statement for the case including the document containing

the statement to the CPS. This message must relate to a witness that the

CPS and police already both know about through the witness being

created on one system and notified to the other via a WM01 or LM04

message.

LM06: New Exhibit - allows the police to send details of a new exhibit

for the case to the CPS.

LM07: New Case Document - this will allow the police to provide the

CPS with documents that will be automatically attached to the case, an

example use of this message might be to supply a Case Summary

(MG5).

LM08: Full File Sent Indication - allows the police to inform the CPS

that they now consider the case file to be a full file. This message does

not imply that all of the information that constitutes a full file has been

sent electronically over the interface only that the paper file should now

be considered to be a full file. The CPS would use this message to




60

trigger the processes that are dependant on the arrival of the full file.

Clearly if the paper file is not yet with the CPS the lawyer may need to

wait for the arrival of the paper file before commencing the review. The

receipt of this message does not prevent receipt of further full case

information.

These five messages may be sent at any point following case registration up

until case finalisation on CMS. The LM04, LM05, LM06 and LM07 may be

sent after CMS case finalisation if the criteria stated in section 4.3.3 are met.

5.1.4 Case Status Updates

The police wish to be notified of key changes to the state of a CPS case and

CPS also need to be able to instruct the police to amend the manner in which

they are building the case file in response to events occurring on the case,

e.g. a case going to trial or an early Guilty Plea. The following messages

have been defined to support this:

FM01: Case Status Change - this will allow CPS to inform the police

that a case has moved from live to finalised; or has moved from finalised

to live; or has been put under appeal. Further, for any of these events the

message will also show whether the case in question has any open

confiscation orders and/or has any defendant who had been the subject of

a conditional caution at any pre-charge decision response.

FM02: Case Action Plan - this will allow CPS to inform the police about

the manner in which the case file should be built in the future. The

message primarily comprises:

1. an action flag indicating that a file build should be started, stopped or

modified;

2. instructions to explain and clarify the action;

3. a date when the action needs completing by;

4. the optional defendant(s) to which the action applies. All defendants

may be included if the action has case wide applicability;

5.1.5 Supporting Split and Merge Post Charge

CPS may take the unilateral decision to split or merge a case anytime once it

has moved into the charge phase. This may be driven by a review of the

case, or following a court order or direction. On the other hand the police

never unilaterally decide to split or merge a post-charge case. They will only

ever do so under instruction from the CPS in order that the organisation of

the cases on the police and CPS IT systems remains compatible to enable

the ongoing bi-directional exchange of messages. These split and merge

activities are supported by two messages:




61

FM02: Case Action Plan - this is the same message discussed above in

5.1.4 although the action flag is extended to indicate a split or a merge

with the other parts of the message indicating exactly how a single case

is to be split or multiple cases to be merged.

FM03: Split/Merge Synchronise - this is used by the police to notify

CMS that they have completed their split or merge of a case. This is the

same message used to support pre-charge merging as described in

4.1.4.1.

The way in which these two messages underpin the post charge split/merge

actions are described below.

Split

When a case with URN xyz is split in CMS the whole of its case content is

distributed between two or more new cases with URNs xyz/1, xyz/2 etc. The

original case xyz is then retired from CMS and referred to as the parent case

in the split. The new cases with split suffices after the URNs (the /1, /2

qualifiers) remain active in CMS and are referred to individually as the child

cases in the split, or collectively as the split children.

Assume CPS has a 2-hander case with URN A that it decides to split. At the

point where the split happens in CMS an FM02 is sent to URN A on the

police system notifying it of the split on CMS and in particular which

defendants and offences will go to which split children. The post charge

split differs from the pre-charge one in that the police are not at liberty to

choose the URNs for the new cases to hold the defendants and offences split

off. They are told on the FM02 what those URNs will be which will all be of

the form <existing URN>/<integer split suffix>.

Events then unfold that affect the ongoing exchange of messages between

the cases on either side as described below.

5.1.5.1 CPS splits

At the point the case split is initiated in CMS the FM02 is sent to the unsplit

police case notifying them that CMS is about to split the case and the police

need to do likewise:

A

Police CPS

AFM02

The split then completes in CMS with the new split child case URNs

acquiring split suffices:




62

A

Police CPS

A/1

A/2

Message transmission from CMS is then affected by the mode the police

operate in (the modes of operation are described in sections 4.1.4.1 to

4.1.4.3). In the blocked mode messages generated from the individual split

cases on CMS are not sent but held back in a queue, i.e.

A

Police CPS

A/1

A/2

X

X

Message 1

Message 2

Message 3

Message 1

Message 2

In the unblocked mode messages generated from the individual split cases

on CMS are all sent back to the unsplit police case. Even though the

messages originate from cases with a split suffix the URNs in the message

will not contain any split suffices, i.e.

A

Police CPS

A/1

A/2

Message 1

Message 2

Message 3

Message 1

Message 2

If the police send messages from their case A to CMS before they split it

then the messages will be handled as follows, regardless of whether they

operate in the blocked or unblocked mode:

Accepted and applied to all split child cases : LM03, LM04, LM04u,

LM05, LM06, LM07, FM03. These messages can reasonably be applied

to the split child cases.

Rejected : CM01, CM03, LM02, LM08. It is not appropriate to apply

these messages to all the split child cases




63

5.1.5.2 Police split

Now the police perform the same split that CPS did. At the point of the split

an FM03 is sent as the last message from the unsplit parent case to CMS

which, as per the rules in 5.1.5.1 above, gets applied to all the split child

cases in CMS, i.e.

FM03A

Police CPS

A/1

A/2

The police then complete the split and end up with the same split child cases

as CMS, i.e.:

Police CPS

A/1

A/2

A/1

A/2

If the police are operating in the blocked mode receipt of the FM03 by CMS

causes any messages held to be immediately released and sent en-masse to

the matching case split child cases on the police side, i.e.

Police CPS

A/1

A/2

Message 1

Message 2

Message 3

Message 1

Message 2

A/1

A/2

If the police are operating in the unblocked mode receipt of the FM03

causes CMS to no longer send messages out from all the split child cases to

the same single case on the police side.

Regardless of the mode, once the FM03 has been received by CMS any new

messages from the split child cases on CMS only go to the matching split

child cases on the police system and vice-versa, i.e.




64

Police CPS

A/1

A/2

A/1

A/2

In both directions these messages would carry the split suffix on their URNs

to ensure they target specific split child cases. Any messages sent with just

the URN stem and no split suffix was now be rejected by both sides.

Again, the choice of blocking mode affects the manner in which messages

are sent from CMS to the police until the police match the split, in much the

same way as described in section 4.1.4.3. The police have the choice of

receiving no more messages until they match the split, or receiving

messages from all the CMS split cases onto their single case.

Note: The FM03 plays an important role in releasing blocked messages in

the blocked mode and preventing any ongoing outbound message re-routing

in the unblocked mode. Whilst CMS is waiting for an FM03 split

confirmation, if it receives messages from the police directly from any of the

split cases without first seeing the FM03 this is considered an error and such

messages will be rejected.

Merge

The post charge merge operates exactly as described for the pre-charge

merge in sections 4.1.4.1 and 4.1.4.2.

5.1.5.3 Managing Victims and Witnesses

When the CPS initiate a post-charge split the victims and witnesses on the

original case all get copied to the split child cases. When CPS performs a

post-charge merge it is possible that the same victim or witness had been

present on both original cases that became merged.

In both these situations the split and merged cases may end up with

unwanted or duplicate victims and witnesses and it is desirable to purge the

case of these to avoid potential confusion and unnecessary management of

the case.

The recommended business process is that whilst the case is in the post-

charge phase it is the CPS who take responsibility for this. Such victims and

witnesses would be removed from CMS which would send WM01u

messages (see sections 5.1.2 and 6.9) to police systems causing a matching

removal to be made there as well.




65

5.1.6 Request for Advice

It will no longer be possible to register advice cases via version 2 of the

ExISS interface.

5.1.7 Data Mastering and Updates

5.1.7.1 Suspects/Defendants

Suspects and defendants may be manually added to a case in both police

systems and CMS. When added in a police system an LM01, LM02 or

CM01 message is sent to create them likewise on CMS and at that point

both systems have the same picture of the suspect/defendant.

Suspects and defendants are only added manually to CMS from case

paperwork if there is a need to view or manipulate their data ahead of its

anticipated receipt from the police, typically in a pre-charge scenario. A

matching create message is not sent to the police here because those

suspects/defendants would be manually created on the police systems

anyway. In such a scenario, when the police CM01 is received at CMS it is

used to update the ASN of the manually created person.

Once police systems and CMS both have the same suspect or defendant they

can freely update it and inform the other side of the updates via LM03 and

DM01 messages. For suspects and defendants the business process does not

deem either side to be the more significant owner of the data and the

agreement is that either side will unconditionally accept the updates sent by

the other overwriting existing values without human intervention or

confirmation. The simple approach avoids the problems of the

suspect/defendant data becoming divergent on either system because each

side is being selective about which parts of any updates it accepts. Hence

both the police and CPS always maintain the same view of the

suspect/defendant as one another and this helps both sides manage the

progression of the case consistently.

Note: Where a suspect or defendant has been created in CMS and doesn‟t

have an ASN the inference is that person is not know in the police system.

Any updates made to it in CMS will not be sent to the police on a DM01. If

the ASN is later acquired in CMS any updates are not retrospectively sent

out at that point but the next time an update is made a DM01 will be sent.

Because the DM01 (like the LM03) contains all the defendant fields, not just

those that have changed, it would give the police a full picture of the

defendant that included all updates accumulated during the period when the

ASN was absent. Note: The ASN is a non editable field in CMS; it can only

be set by then police providing a value on an LM01, LM02, LM03 or

CM01.




66

5.1.7.2 Victims and Witnesses

5.1.7.2.1 Updates

Victims and Witnesses may be manually added to a case in both police

systems and CMS. When added in a police system an LM04 message is sent

to create them likewise on CMS and when added on CMS a WM01 message

is sent to create them likewise on the police system. At that point both

systems have the same picture of the victim/witness and can freely update it

and inform the other side of the updates via LM04u and WM01u messages.

Unlike defendants though, the data on the updates messages is not always

unconditionally accepted. The Witness Care Units (WCU) are sensitive to

the values of contact information (addresses, phone numbers and alternative

contacts)6 because WCU staff they are typically the prime point of routine

contact with the witnesses; thus they reserve the right to audit any contact

data updates made by the police. Similarly the police are considered the

definitive source of information on police witnesses and WCU staff don‟t

need to be involved in managing updates to police witness data. These

principles have led to the following agreements on managing witness

updates:

Agreement 1) : CMS will unconditionally (i.e. without human intervention

or confirmation) accept updates on an LM04u in the following situations:

The witness is a police witness. (Contact and non-contact data accepted);

The witness is on a case not yet allocated a Witness Care Office (WCO)

working in a WCU. (Contact and non-contact data accepted);

The witness is not a police witness and allocated to a WCO. Non contact

data accepted and contact data for which no value is currently set on

CMS);

Agreement 2) : If contact data updates for a witness or victim is received by

CMS on an LM04u for non police witnesses allocated to a WCO and there

are already different7 data values in CMS, the WCO can review these

updates and accept or reject each of these changes. If all updates are

accepted no further action is required. If any updates are rejected then a

WM01u is sent to the police with the full details of the witness as it now

stands on CMS. The contact fields which have been rejected will be

different to that held on the police systems. The WM01u will be

accompanied by a single rejection reason to explain why the updates were

rejected.

6 These are defined more rigorously at the end of section 6.8.7.

7 This includes the situation where a value is set in CMS but the value on the incoming

WM01u is blank, implying an attempt to delete an item of contact data.




67

Agreement 3) : Police unconditionally accept all non contact updates

received on a WM01u from CMS.

Agreement 4) : The Police may review contact updates received on a

WM01u. If all updates are accepted no further action is required. If any

updates are rejected then an LM04u is sent back to CMS with the full details

of the witness as it now stands on the police system. The contact fields

which have been rejected will be different to that held on CMS. The LM04u

will be accompanied by a single rejection reason to explain why the updates

were rejected.

The police systems and CMS may thus trade victim/witness updates via a

series of WM01u/LM04u messages until one side eventually fully accepts

the other‟s updates. Whether the police choose to review contact updates or

just unconditionally accept them would be the subject of agreement between

them and their related CPS area and be recorded in the IBA.

Note: Since the TWIF interface went live in November 2011 an alternative

mode of conduct for managing witness updates has emerged from some

forces which is contrary to the principles outlined in Agreements 3 and 4

above. The implications for this are explained in more detail in H.4.5.

Agreement 5) : If either side updates contact information a reason for that

must be supplied in the update message to help justify it to the other party

and reduce the incidence of update rejection and subsequent return of

another update message.

Agreement 6) : CPS will never send the police a WM01u if it updates a

police witness as the police system is considered the master data source for

these.

5.1.7.2.2 Deletions

An individual in CMS and police systems may be a witness, a victim or both

a victim and witness, although regardless of which of these flavours the

individual is tagged with it is assumed that any given physical person is

recorded on a system with a single Unique Id. If either side amends such an

individual to alter them in any of the following ways:

Amending a person who is a victim and witness to be just a victim;

Amending a person who is a victim and witness to be just a witness;

Amending a person who is just a victim to be just a witness;

Amending a person who is just a witness to be just a victim.

Then that person is still considered to exist on the system and the change to

their victim/witness identity should be communicated to the other side using

LM04u or WM01u messages operating in update mode even though

logically their victim or witness aspect has been deleted.




68

It is only where an individual is removed entirely on a system so that no

aspect of their victim or witness persona remains that an LM04u or WM01u

should be used in delete mode to tell the other side that the person has been

deleted.

When one side receives a deletion notification (i.e. an LM04u or WM01u

operating in delete mode) from the other two options are available:

1. The notification is rejected and an LM04u or WM01u operating in delete

rejection mode is sent back to the other side. The business process puts

no demands on how such a rejection message should be handled but the

expectation is that, where possible, the side receiving the rejection

message would un-delete the victim/witness they previously deleted.

This assumes the deletion was done logically at the outset and can be

logically undone later if necessary either automatically or manually

(CMS would certainly be the latter). If this is not the case then the CPS

and police force in question would need to agree between them how the

disparity in the existence of the witness should be handled, by either the

rejecting side performing the delete after all, or the original deleting side

re-creating the witness. It is anticipated that the incidence of this

happening will be sufficiently low that it not considered of sufficient

business benefit to agree a more elaborate scheme to manage the data in

such a case. Note: If one side has deleted a witness and the other side

rejected that deletion then any witness update messages received by the

side that performed the original deletion will be rejected until such a

time as they reactivate their witness.

2. The notification is accepted and the matching delete performed as well.

When completed, no further message needs to be sent back to the side

originally notifying the delete, i.e. the delete does not need to be

confirmed. Note: if one side supports logical deletion and after

performing a matching delete in response to a deletion request decides at

a later date to re-activate a witness then the business process does not

define what happens in this situation. In particular, there is no variant of

the LM04u/WM01u message to tell the other side to re-activate a

witness. This is considered such an unlikely scenario that any

discrepancies arising from this will be resolved manually between CPS

and the police force in question.

Both the Police and CMS may delete a witness regardless of whether or not

they are a police witness, a professional one or a civilian one and it is then

the responsibility of the other side to accept the deletion or reject it as

unacceptable. In particular this includes CPS deleting a police witness.

Whilst this is unlikely, the business process does still allow the police to

reject the deletion if it is inappropriate.

Merge Deletions

It is possible that a case with a witness could be split causing the witness to

be copied to the two child cases. Those child cases could then be re-merged

causing the resultant merged case to acquire two instances of the witness




69

each with the same Unique Id. If the duplication is noted and one of the

copies of the witness deleted in one system this will not cause a „phantom‟

WM01u or LM04u in delete mode to be sent out to the other system because

the witness with the Unique Id still exists on the case. A WM01u or LM04u

in delete mode should only be sent out when removing the victim or witness

would remove the last occurrence of their Unique Id from the case.

Sections 6.8.1 and 6.8.7 describe in more detail how the LM04u/WM01u

message contents reflect whether the message is operating in update, delete

or delete rejection mode.

5.2 Message Model Diagram

The diagrams in this section show the proposal for a message model.

Section 6 of this document provides a detailed definition of the data that

these messages transmit and the constraints upon their use.

5.2.1 Charge Case

A prosecution may be commenced by,

Charge.

Summons, following the laying of an information.

Postal Requisition.

Throughout this document expression Charge includes Charge, Summons,

and Postal Requisition.

The first diagram illustrates the message model used for a Charge case. The

LM01 message is used to send the initial case material (even if a paper

advice file for this case has already been submitted to CPS). The initial

material is followed by any number of messages for new defendants,

witnesses and statements, exhibits and case documents. When the police

have assembled and sent the electronic full file, an LM08 is sent to indicate

this. Following the full file, additional messages may be sent as required to

provide additional information.




70

Police CPS

Police Prepare Case Material

Submit Initial Case Information

Ongoing investigation/full file preparation

Full File is Ready

Case Registered on CMS LM01 : Initial Case Information

LM02 : New Defendant

LM04 : New Witness

LM05 : New Witness Statement

LM06 : New Exhibit

LM07 : New Case Document

LM08 : Full File Sent Indication

Ongoing

investigation/prepare additional material

Ongoing

prosecution/Receive and process new info

Full file received

Ongoing

prosecution/Receive and process new info

Finalisation on CMS

Sent in any order and as many times as needed

LM02 : New Defendant

LM04 : New Witness

LM05 : New Witness Statement

LM06 : New Exhibit

LM07 : New Case Document


WM01 : New Witness

WM01u : Updated Witness

DM01 : Updated Defendant

FM02 : Case Action Plan


FM01 : Cased Finalised Indication

LM03 : Updated Defendant

LM04u : Updated Witness

Figure 5 : Generic Business Messages for a Charge case.

For each message, a business response will be produced that is passed back

from the CPS to the police. Section 6.21 describes the mechanism used for

sending these responses.

5.2.2 Post-charge Split Case

The second diagram illustrates the message model used for when a charge

case is split in conjunction with a force operating in the blocked mode. The




71

LM01 message is used to send the initial case material for a 3 handed case

along with put charges and scheduled hearings. After the 1st hearing has

happened, the CPS lawyer and courts make a decision that one of the

defendants should be prosecuted under a separate URN and the case is split

post-charge. Unwanted witnesses carried forward onto both split cases and

then selectively removed in CMS and the police notified of this via WM01u

messages. Both split cases then proceed as ordinary charge cases.

Police CPS

Police prepare and submit

initial case information


3 Defendants added to case

with URN A

LM01: Initial Case Information

1st hearing held and CPS

prosecutor splits one

defendant onto URN A/2 and

the other two onto URN A/1

Witnesses deleted from A/1

Witnesses added to A/2

(both messages held back)

Police receive instruction

and pass it to an officer’s

work queue

FM02: Action Plan with

split case instruction

Police complete split as

instructedSplit confirmation received

FM03: Confirm split

Messages held back are

immediately released

Delayed messages

received and applied to

individual split cases

WM01u : updated witnesses

WM01 : new witness

WM01u : updated witnesses

WM01 : new witness

Figure 6 : Message flows for a post-charge split case.

5.3 Business Events

The logical message definitions in section 6 of this document reference a

number of business events as constraints. This section defines the business

events referenced in section 6.

5.3.1 Registration

Registration is the CPS business event of recording on the Compass CMS

that a new case has been received by the CPS. There are four types of

registration supported by CMS which are the same as described in section

4.3.1. Any type of registration may be performed before or after the first

hearing for the case.




72

5.3.2 Full File Indication

Police indicate that they believe that a full file has now been prepared and

despatched to the CPS. All information received up to this point constitutes

the digital material that the police have available for full file.

5.3.3 Finalisation

Finalisation of the prosecution case on the Compass CMS. Once a case is

finalised on CMS, CMS will reject further messages received via the

interface, indicating that the case is finalised. The exception to this is if the

case meets the criteria discussed in 4.3.3 It is expected that the police will

also have finalised their case at this point.

CMS supports the concept of case reactivation, this returns the case to a live

state and would allow further messages to be received for the case from the

police. Case reactivation on CMS is a manual activity and it will not be

triggered via receipt of a message over this interface except, again, as

discussed in 4.3.3.




73

6 Logical Message Model

6.1 Overview

This section describes the individual logical messages used to pass data

between police IT systems and Compass CMS.

A sub-section is included below for each of the logical messages. These sub-

sections provide, for each message:

A description of the message.

The constraints placed on the message. For ease of reference, the

same list of constraints is presented in tabular form for every

message, with the applicability of each constraint to the message

specified alongside.

The data items contained within the message, presented as a diagram.

These diagrams give a high level view of the data and do not attempt

to give a complete data definition, which will be provided by an XML

schema defined in the physical model.

The physical message model may present these logical messages in a

different form.

All messages are optional: they may or may not be sent. If they are sent,

they must conform to the constraints laid down in the sub-sections.

Not all data items or relationships within the messages will be stored in

CMS as structured data items. Certain data items and relationships have

been included in the message to aid in future proofing the interface. Data

items that CMS does not make use of will still be subject to XML

validation, and CMS itself may also perform some validation of this data.

6.1.1 Unique Identifiers

Messages transmitted between the police and CPS will contain case

information and suspect information. To ensure that the police and CPS both

know they are referring to the same suspect or case in the messages each

entity will be uniquely identifiable.

At the highest level, all data is associated in some way with a case. Cases

will be uniquely identified by PTI URN including a split suffix if

appropriate to denote a case that has undergone a split operation.

Each physically different suspect or defendant in the real world must be

uniquely identifiable across all cases in order to support splitting and

merging (see sections 3.4.4 and 3.5.5). Cases split by offence in CMS may

result in the same real world suspect on different cases having the same

Unique Id. Whilst the police‟s matching split is outstanding defendant level

messages sent from them will be applied to all instances of that defendant




74

across the CMS split cases and defendant level messages from any of those

CMS split cases will be applied to the single instance of the defendant on the

police system.

Cases merged in CMS could contain 2 instances of a real world defendant

with the same Unique Id. Similar to the split scenario, whilst the matching

police merge is outstanding defendant level messages sent from any of the

unmerged police cases to CMS will be applied to both instances of the

defendant on CMS, and defendant level messages from either instance of the

merged defendant on the CMS case will be sent to all individual instances of

the defendant on the police cases. These same principles also apply when a

case contains 2 instances of a real world witness with the same Unique Id.

Other unique identifiers will be required to provide support for future and

existing messaging interfaces such as ExISS and Libra. These are:

Offences (both police proposed charges and CPS advised charges);

Victims and witnesses;

Witness statements;

Exhibits;

Case documents;

Pre-charge consultations;

Other case individuals, e.g. Solicitor, officer in case.

As some identifiers are only required to be unique to a case, it is possible

that the same unique ID could be used in different cases.

If a message is intended to create a new instance of any of these items, the

message will be rejected if the unique identifier provided in the message

already exists for that entity within its case.

6.1.2 Diagrammatic Notation

The sections below show a series of diagrams detailing the structure of the

messages to be passed between the police and the CPS. These diagrams are

only intended to provide guidance. The XML schema produced for the

interface will be the definitive guide to the data passed between the two

organisations.

Items marked with a solid frame in the diagrams are mandatory.

Items marked with a broken frame are optional.

Items marked with a “+” are made up of a number of items; these items have

been removed from the diagram to aid clarity and are detailed later on in the

document.




75

Items that have a number associated with them, e.g. 1…∞, indicates the

number of items that must exist. The example detailed states that there must

be at least one item but there is no upper limit on the number of items that

you may have.

6.2 General Message Rules

A number of general rules apply to all of the messages exchanged between

the Police Systems and CMS (unless specified in the table below). These

general rules will be checked in addition to the rules specific to the

individual business message.

If a general rule is violated then the resulting business response is shown in

the table below. The business response code cross-references the business

response definitions in section 6.21.

6.2.1 General Message Receipt Rules

The following rules will be validated when a message is received:

Ref Business Rule Applied by

Receiving

System

Applies to

Message

Response on

Failure

MG01.1.1 Message received with a recognised

URN., i.e. simply that a case exists (in

any state) on CMS with the URN.

CMS LM02

LM03,

LM04

LM04u

LM05

LM06

LM07

LM08

CM03

FM03

BE2

MG01.1.2 Message received with a recognised

URN.

POLICE LM07

CM02

WM01

WM01u

FM01

FM02

DM01

BE2




76


Receiving

System

Applies to

Message

Response on

Failure

MG01.1.3 Whilst a police split is outstanding,

message received for a case that has

not been split, i.e. has no split children.

(Note: if URN xyz has been split into

xyz/1 and xyz/2 and then xyz/2 later

split further into xyz/3 and xyz/4 the

message will be rejected if sent to

URNs xyz or xyz/2 as it is only xyz/1,

xyz/3 and xyz/4 that have no split

children.

As per the end of para 5.1.5.1, if CMS

splits and the police have yet to do so,

then messages sent from the unspilt

case to CMS will be routed on to all the

split child cases on CMS except for the

4 listed opposite which will be rejected

with the BE12 error. )

CMS CM01

CM03

LM02

LM08

BE12

MG01.1.4 Message received must be for a case

that is either live or subject to

confiscation orders or conditional

cautions.

CMS LM04

LM04u

LM05

LM06

LM07

BE5

MG01.1.5 Message from a split case must be

received after CMS has been notified

of the police‟s completion of the split

via an FM03.

CMS LM02

LM03

LM04

LM04u

LM05

LM06

LM07

LM08

CM01

CM03

FM03

BE49

MG01.1.6 Message received must be for a case

that is live.

CMS LM02

LM03

LM08

CM03

BE5

MG01.1.8 Message received must refer to a Court

which has been set up in CMS.

CMS LM01,

LM02,

CM03

BE3




77


Receiving

System

Applies to

Message

Response on

Failure

MG01.1.9 Message received must be for a case in

one of the following states Live,

Finalised or Pending Admin

Finalisation.

CMS LM02

LM03

LM04

LM04u

LM05

LM06

LM07

LM08

CM01

CM03

FM03

BE23

MG01.1.10 A Suspect/Defendant with matching

Unique Id exists on the case.

CMS CM03

LM03

BE16

MG01.1.11 A Suspect/Defendant with matching

Unique Id (excluding 0) exists on the

case.

POLICE CM02

DM01

FM02

BE16

MG01.1.12 Message not supported on non-charge

case.

CMS CM01

CM03

FM03

LM01

LM02

LM03

LM04

LM04u

LM05

LM06

LM07

LM08

BE22

MG01.1.13 Message provides values in the general

classification structure at the

appropriate level. (i.e. Exhibits not

assigned People classifications)

CMS CM01

CM03

FM03

LM01

LM02

LM03

LM04

LM04u

LM05

LM06

LM07

LM08

BE37

MG01.1.14 Data supplied in the classification

structure may not contain duplicate

values as specified in D.1.4.

CMS CM01

CM03

FM03

LM01

LM02

BE38




78


Receiving

System

Applies to

Message

Response on

Failure

LM03

LM04

LM04u

LM05

LM06

LM07

LM08

MG01.1.15 The EXISS version of the message

must match the version of the EXISS

interface supported by the Police Force.

CMS CM01

CM03

FM03

LM01

LM02

LM03

LM04

LM04u

LM05

LM06

LM07

LM08

BE39

MG01.1.15 The EXISS version of the message

must match the version of the EXISS

interface supported by the Police Force.

POLICE CM02

FM01

FM02

LM07

WM01

WM01u

DM01

BE39

MG01.1.16 Types, Codes and Values provided in

the general classification structure

identify valid combinations

documented in the TWIF interface

specification.

CMS CM01

CM03

FM03

LM01

LM02

LM03

LM04

LM04u

LM05

LM06

LM07

LM08

BE40

MG01.1.17 Associated URN for a pre-charge split

association type relates to a case with a

URN that is recognised.

CMS CM01

LM01

BE32

MG01.1.18 Message received contains no Person

classification codes that are not

applicable to the type of person are

classifying as defined in D.3.

CMS LM01

LM02

LM03

LM04

LM04u

CM01

BW02




79


Receiving

System

Applies to

Message

Response on

Failure

MG01.1.19 Message received contains no Person

classification codes that are not

applicable to the type of person are

classifying as defined in D.3.

Police DM01

WM01

WM01u

BW02

MG01.1.20 Message received contains optional

victim and witness data consistent with

the type of person the individual is

declared to be. Specifically:

if TypeOfPerson = Victim then

neither the Witness nor

WitnessAndVictim nodes should

be provided.

if TypeOfPerson = Witness then

neither the Victim nor

WitnessAndVictim nodes should

be provided.

if TypeOfPerson = VictimWitness

then neither the Witness nor

Victim nodes should be provided.

CMS LM04

LM04u

BE47

MG01.1.21 As per MG01.1.20 Police WM01

WM01u

BE47

MG01.1.22 If present, the Parent/Guardian,

Defence Solicitor, Alternate Contact

UniqueId must be unique within the

case

CMS LM01

LM02

CM01

BE17

MG01.1.23 If present, the Alternate Contact

UniqueId must be unique within the

case

CMS LM04

LM04u

BE17

MG01.1.24 The Offence Unique Id for an offence

associated with a defendant being

created/updated must be unique within

the case.

CMS LM01

LM02

CM03

BE14

MG01.1.25 Message conforms to defined schema

definition.

CMS All BE100

6.2.2 General Message Sending Rules

The following rules will be validated before a message is sent:


Sending

System

Applies to

Message

MG01.2.1 Each message will be validated against the schema

[SCHEMA2] before being sent.

CMS,

POLICE

All

MG01.2.2 The highest classification of any information

transferred across the interface is RESTRICTED.

CMS,

POLICE

All

MG01.2.3 The correct version of the EXISS message will be

distributed depending on the version of EXISS

supported by the Police Force.

CMS,

POLICE

All




80


Sending

System

Applies to

Message

MG01.2.4 Messages will only be sent from a case in CMS to a

police system where it is known that the case exists on

the police system:

due to the previous receipt by CMS of a v2 CM01

or LM01 for the case‟s URN; or

because the case had been the subject of previous

ExISS v1 traffic.

CMS All

MG01.2.5 Further to MG01.2.4 messages specific to

suspect/defendants will only be sent from CMS to a

police systems if the suspect/defendant‟s ASN is

recorded within CMS as this allows CMS to know that

the suspect/defendant exists on the police system and is

able to receive messages.

CMS CM02

DM01




81

6.3 LM01 - Initial Case Material

6.3.1 Description

This message contains the initial case material sent by the Police,

corresponding to an expedited case file.

The LM01 message must include at least one defendant. For each defendant,

charges must be supplied.

CMS has a concept of core data items. If during manual case registration the

core data items are not provided then tasks are raised to chase the police for

the missing items of core data. The following items are core data for charge

cases on CMS: PTI URN, Defendant (surname, date of birth and ethnicity),

first hearing date.

CMS models pre-charge cases and charge cases as one and the same case. If

a case begins life as pre-charge case and then moves into a charge phase

further pre-charge suspects may be added to the case via CM01 messages or

charged defendants not subject to statutory charging added via LM02

messages.

6.3.2 Summary of changes between version 1 and version 2

The LM01 message at version 2 will no longer be able to create „Advice‟

cases. As such, defendants are no longer optional with the LM01 message.

The LM01 message at version 2 will no longer be able to register a pre-

charge case. As such, supplying a defendant as well as an offence for each

defendant and a first hearing is now mandatory in this message.

The Case Monitoring codes will now be transmitted using the generic

classification scheme. More details about this can be found in Appendix

D.2. Likewise person level classifications have been moved to the generic

classification structure and further details can also be found in Appendix

D.3.

When specifying the URNs of an associated case, an association type must

also be provided to describe how that case is associated to the new case that

is being registered.

The flag to indicate whether a defendant was passed through custody will be

replaced with an “Initiated By” item, which will show how the charge

process was initiated.

The value „Reported‟ will be added to list of available values for „Police

Remand Status‟.

Values for a defendant‟s „Religion/Belief‟ and „Disability‟ may also be

provided in this message, by providing these values from those listed in

Appendix D.3.




82

The defendant‟s police bail conditions can now be optionally provided.

When offence details are provided an optional Charge Date can now be set

and the v1 Recordable flag has been removed as this is maintained within

CMS configuration data and not required on the message.

The „Station‟ element of the Police Officer Contact Details is now optional

allowing Rank and Shoulder Number to be provided without having to

specify the station. Any station details provided will only be used in CMS

where a default police station is not configured in CMS.

If a freetext Rank value is provided CMS will only store it if it is in this list :

{CI, INS, DI, PS, DS, PC, DC, SC, PCSO}. Any other values will be

ignored but not otherwise affect the rest of the message processing.

It will no longer be possible to send victim details in this message. Victims

should be sent using the LM04 instead.

6.3.3 Constraints

Constraint Value

Sender Police IT System

Recipient Compass CMS

Must be sent after (No constraint)

Must be sent before Registration on CMS

Can cause registration Yes, receipt of this message within the above constraints

will always cause electronic registration

Applicable to Charge case Yes

How often Once only

6.3.4 Message Receipt Rules

The following rules will be validated when the message is received:

Ref Business Rule Response on

Failure

LM01.1.1 Message received for CPS unit known to CMS. BE18

LM01.1.2 Message received with URN not known to CMS. BE1

LM01.1.3 Associated URN for a co-consideration association type is not

relevant and should not be provided.

BW03 -

Warning

Message

6.3.5 Message Sending Rules

The following rules will be validated before the message is sent:

Ref Business Rule

LM01.2.1 This message can only be sent from the Police to CMS.

LM01.2.2 Message can only be sent once post charge for a case.




83

6.3.6 Message Triggers

The following table indicates when an LM01 message can be sent:

Ref Source Trigger

LM01.3.1 Police New charge case registered in Police Systems.

6.3.7 Data

The data items carried by this message are specified in the following

diagrams. Note that due to the size of this message the message is shown in

a number of figures. The first is a top level figure, with subsequent figures

showing the expansion of various elements within the figure.




84

Figure 7 : The high level structure of the LM01 Initial Case Material

logical message.

Defendant can either be a PersonDefendant or an OrganisationDefendant.

The CaseClassification element uses the Classification structure described in

Appendix D.2. The Associated Cases element uses the Case Association

structure. The AssociatedPTI-URN element uses the PTIURN Structure.

Figure 8 - An expansion of the PTIURN element, which uses the

PTIURN Structure




85

Figure 9 - An expansion of the CPS Unit element which uses the

Organisation Location Code structure.

Figure 10 : An expansion of the Defendant element.




86

This shows expansion of the NextHearing element structure as well as the

expanded Court Id.

Figure 11 : An expansion of the Person Defendant element.




87

The PersonClassification element uses the Classification Structure, which is shown

in the high level structure of the LM01 Initial Case Material message.

Figure 12 - An expansion of the Name element

Note : Here, and in all messages where the Name element is used, only the

Title, GivenName and FamilyName fields will be used by CMS. The other

fields are included as part of the Data Standard 4.3 definition but not used in

CMS and any content provided therein will be ignored.

Figure 13 - An expansion of the PersonClassification element




88

Figure 14 - An expansion of the Alias element

Figure 15 - An expansion of the PNCId element




89

Figure 16 - An expansion of the ParentGuardian element, which uses

the standard base person structure.

Figure 17 : An Expansion of the Organisation Defendant element.

The OrganisationClassification element uses the Classification structure

described in Appendix D.12 This classification structure is present in this

message to be used in the future and will not be used for any purpose at

present.




90

Figure 18 - An expansion of the ASN element.




91

Figure 19 : An expansion of the Offence element within the Defendant

element.




92

The expansion of the CJSCode is the same as the OffenceCode within the

CPR as shown in Figure 21 below.

Figure 20 - An expansion of the CPR element within the Offence

element

Figure 21 - An expansion of the CJSCode element within the Offence

element




93

Figure 22 : An expansion of the DefenceSolicitor element structure

within the Defendant element.

The PersonClassification element uses the Classification Structure, which is

shown in the high level structure of the LM01 Initial Case Material message.

The Name element has the same expansion as the Alias name shown in

Figure 12.




94

Figure 23 - An expansion of the ContactDetails element, used in the

Person Defendant, Organisation Defendant, Defence Solicitor and

Officer In Case elements. This also shows the expanded Address,

Contact Number and DX Address elements.

CMS can only store once instance of each type of telephone number (home,

work, mobile, fax). If multiple instances of a single type are provided in the

message (e.g. 3 work numbers) only the first such instance will be used and

all others ignored. Any DXAddress data supplied is ignored by CMS.




95

Figure 24 : An expansion of the PoliceContactDetails element (which

uses the Police Officer structure).

Note that the unexpanded items are exactly the same as those for the

defendant (as shown in the preceding diagrams). Whilst the

PersonClassification is included in the structure it is not expected to be used

and CMS would ignore any content it provides.

The Initial Case Material message includes a mandatory field identifying the

CPS unit to which the message should be routed. This is necessary for

Compass CMS to handle the message, because if the message causes

registration of a new case, that new case must be owned by a CPS unit. The

other messages in this interface do not allow a unit to be specified, as they

can only be used for a case that has already been registered, so the owning

unit will already have been determined, and possibly changed by the CPS.




96

6.4 LM02 - New Defendant

6.4.1 Description

This message allows a single defendant to be added to an existing case. The

message must contain the URN of the case to which the defendant is to be

added, the defendant details and offences with which that defendant has

been charged.

The message must also include a unique identifier for the defendant. The

message will be rejected if a defendant already exists with the unique

identifier provided.

The message can contain information for only one defendant and must

contain one or more offences and a first hearing for the defendant.

It is possible to add a defendant to a case after it has been split by the CPS

though this requires the Police to specify the URN and the split suffix of the

child case to attach the defendant to.

Once a defendant has been added to a case, it is not possible to amend their

offences or to add new offences via this message.


The LM02 has not changed significantly other than inherit revised data

structures that it shares with the v2 LM01 message.

6.4.3 Constraints

Constraint Value



Must be sent after Case has been registered

Must be sent before Case finalisation

Can cause registration No

How often Once for each defendant. As many times as required for a

case.




Failure

LM02.1.1 Defendant with this unique Identifier and URN does not already

exist.

BE41




97



Ref Business Rule


LM02.2.2 This message can only be sent against a case which already exists on CMS, either through

manual or electronic registration.



Ref Source Trigger

LM02.3.1 Police New defendant added to a charge case in Police Systems.

6.4.7 Data


diagram:

Figure 25 : The structure of the LM02 New Defendant logical message.

Note that the contents of the elements within LM02 are the same as the

contents for the same elements within LM01. Defendant can either be a

PersonDefendant or an OrganisationDefendant.




98

6.5 LM03 - Updated Defendant

6.5.1 Description

This message allows the police to send updates to an existing defendant on

the case to the CPS. The message must contain the URN of the case the

defendant belongs to along with the unique identifier of the defendant. The

message will be rejected if a defendant with the unique identifier does not

exist on the case.

The message can contain information for only one defendant. If more than

one defendant is to be updated, a separate instance of this message must be

sent for each of those defendants.


This message is new in version 2.

6.5.3 Constraints

Constraint Value



Must be sent after Case Registered in CMS and defendant added to case in

CMS

Must be sent before Case finalisation on either system


How often As many times as required for each defendant




Failure

LM03.1.1 If present, the Parent/Guardian UniqueId must be unique within the

case

BE17



Ref Business Rule


LM03.2.2 This message can only be sent against a case which already exists on CMS and contains

the defendant to be updated.




99



Ref Source Trigger

LM03.3.1 Police Existing suspect/defendant updated in pre-charge or charge case by Police,

other than when updated because of receipt of a DM01.

6.5.7 Data


diagram:

Figure 26 - The structure of the LM03 Updated Defendant logical

message.

Note that the contents of the elements under the UpdatedPoliceDefendant

node within the LM03 are the same as the contents for the same elements

under the Defendant node within the LM01, with the exception that the

Hearing, Defence Solicitor and Offence details cannot be updated so they

will not be included in this message. The optional Police Bail Date is

provided as part of PersonDefendant which is absent on the LM01 and

LM02 as the first hearing on those messages represent the point where the

suspect is returned to custody. The defendant can either be a

PersonDefendant or an OrganisationDefendant.

Within the PersonDefendant and OrganisationDefendant elements the LM03

also contains a VersionNumber field to help the CPS and Police synchronise

their views of the defendant. This use of this is explained further in

Appendix H.4.




100

When a defendant‟s details are updated all the values of the defendant are

supplied in the message as they stand at the point of the update, not just the

values that actually changed in the update.




101

6.6 LM04 - New Witness or Victim

6.6.1 Description

This message allows a new witness or victim to be added to a case by the

police. The message must contain the URN of the case to which the witness

or victim is to be added and the witness or victim details.

The message must also include a unique identifier for the witness or victim.

The message will be rejected if a witness or victim already exists with the

unique identifier provided. The police will allocate the unique identifier

when they create the witness or victim and this will be used to refer to the

witness in any future with update messages (LM04u or WM01u) or witness

statement (LM05) messages exchanged.

The message can contain information for only one witness or victim. If more

than one witness victim is to be added, a separate instance of this message

must be sent for each of those witnesses and victims. If a person is both a

victim and a witness, however, this message can add them to the case as

both types of person at the same time.

It is not possible to send witness statements using this message. If witness

statements are to be sent electronically, one or more LM05 - New Witness

Statement messages shall be sent after the LM04.


The LM04 now uses the more generic Classification structure to model the

type of Witness attributes. The NoDirectContact and PreviousConvictions

flags have moved into this generic structure. The Victim flag has been

removed and replaced with an explicit TypeOfPerson attribute denoting

whether an individual is a victim, a witness or both.

For police witnesses it is now possible to send data on their rank, shoulder

number and Warrant Card Id. The comment on rank data in 6.3.2 applies

here as well.

The LM04 can now send victims, including victims who are not also

witnesses. The LM04 can include victim-offence links, allowing victims to

be marked as victims of specific offences on CMS/WMS. These offences

must have been added to CMS/WMS by previous ExISS messages e.g.

LM01, LM02 or CM03.

6.6.3 Constraints

Constraint Value



Must be sent after Case Registered in CMS

Must be sent before Case finalisation on police system. Case finalisation on

CMS unless case has asset recovery work or conditional




102

Constraint Value

cautions.


How often Once for each victim or witness, As many times as required

for each case.




Failure

LM04.1.1 Message received for Witness or Victim with Unique Identifier is

not already in use on the case as specified by the PTI-URN for

another person.

BE42

LM04.1.2 Message received containing no Offence Identifiers not known to

CMS.

BE28



Ref Business Rule

LM04.2.1 This message can only be sent from the Police to CMS

LM04.2.2 This message can only be sent against a case which already exists on both the CMS and

Police systems, either through manual or electronic registration.



Ref Source Trigger

LM04.3.1 Police New witness or victim added to pre-charge or charge case in Police.

(Other than by a WM01 message from CMS).

6.6.7 Data


diagrams.




103

Figure 27 : The structure of the LM04 New Witness logical message.




104

Figure 28 : The structure of the Person element within the LM04 New

Witness logical message.




105

The Witness and Victim elements under WitnessAndVictim are identical to

those shown as expanded above them. The TypeOfPerson field is used to

declare whether the individual is a pure victim, a pure witness or both a

victim and witness. The optional OR branch at the bottom of the structure

then allows further victim or witness specific information, if it exists, to be

supplied for the type of person. (Note: The „dummy‟ element under the

Victim node should always be ignored, i.e. neither read nor written. Its

presence is required as a work around to a technical issue with the Microsoft

.NET environment when deserialising the XML.)

Figure 29 : The structure of the AlternateContactStructure element

At present, CMS will only use data in the PersonClassification structure if it

identifies the alternate contact as having Welsh as their preferred language

or provides a value for their ethnicity, gender, religion/belief or disability

(see D.3). Any other values provided will be ignored but not cause the

message to be rejected.




106

6.7 WM01 - New Witness or Victim

6.7.1 Description

This message allows a new witness or victim to be added to a case by CMS.

The message must contain the URN of the case to which the witness or

victim is to be added and the witness or victim details.

The message must also include a unique identifier for the witness or victim.

The message will be rejected if a witness or victim already exists with the

unique identifier provided. CMS will allocate the unique identifier when

they create the witness or victim and this will be used to refer to the witness

in any future with update messages (LM04u or WM01u) or witness

statement (LM05) messages exchanged.


than one witness victim is to be added, a separate instance of this message

must be sent for each of those witnesses and victims. If a person is both a

victim and a witness, however, this message can add them to the case as

both types of person at the same time.

Unlike the LM04 message, the new witness message from CMS to the

Police does not include any victim level offences.


This message is new in ExISS v2.

6.7.3 Constraints

Constraint Value

Sender Compass CMS

Recipient Police IT System

Must be sent after Case Registered in CMS and on police system.

Must be sent before WMS finalisation on CMS. Case finalisation on police

system.


How often Once for each victim or witness, As many times as required

for each case.




Failure

WM01.1.1 Message received for Witness or Victim with Unique Identifier is

not already in use on the case as specified by the PTI-URN for

another person.

BE42




107



Ref Business Rule

WM01.2.1 This message can only be sent from CMS to the Police.

WM01.2.2 This message can only be sent against a case which already exists on both the CMS and

Police systems, either through manual or electronic registration.


The following table indicates when an WM01 message can be sent:

Ref Source Trigger

WM01.3.

1

CMS New witness added to Pre-charge or charge case in CMS/WMS. (other

than by an LM04 message from the Police).

6.7.7 Data


diagrams.

Figure 30 : The structure of the WM01 New Witness or Victim logical

message.

The Person element has the same structure as the one defined in the LM04,

although the OffenceId part of the Victim element would never be

populated. Similarly, CMS will only use the PersonClassification structure

for an alternate contact to identify Welsh as their preferred language or

provide a value for their ethnicity, gender, religion/belief or disability.

Witness.Rank/WarrantCardID values will never be set on a WM01.




108

6.8 LM04u - Updated Witness or Victim

6.8.1 Description

This message allows:

The police to send updates for an existing witness or victim on the

case. Section 5.1.7.2.1 describes the exchange of witness updates

between the police and CPS (update mode).

The police to indicate a witness or victim deletion as described in

section 5.1.7.2.2 (delete mode).

The police to reject updates to contact information of non-police

witnesses provided by CPS on the WM01u message as described in

5.1.7.2.1 (update rejection mode).

The police to reject a deletion of a witness or victim provided by

CPS on the WM01u message as described in section 5.1.7.2.2 (delete

rejection mode).

The message must always contain the URN of the case the person belongs to

along with the unique identifier of the person and their current version

number. The message will be rejected if a witness or victim with the unique

identifier does not exist on the case with the exception of it relates to the

police rejecting a deletion of a witness or victim. In this instance, the

witness would have previously existed (prior to its deletion) on the case.

Further, the message will contain the full details of the witness or victim as

it stands unless it relates to the witness or victim deletion variant stated in

the 2nd

bullet above in which case only the Unique Identifier of the witness

or victim, their current version number and the reason for the deletion will

be provided.


than one witness or victim is to be updated, a separate instance of this

message must be sent for each of those witnesses.



6.8.3 Constraints

Constraint Value



Must be sent after Case Registered in CMS and witness added to case in

CMS. A witness may be marked as deleted from the case if

the message relates to the police rejecting a deletion made

by CPS




109

Constraint Value

Must be sent before Case finalisation on police system. Case finalisation on

CMS unless case has asset recovery work or conditional

cautions.


How often Once for each time a witness is updated. As many times as

required for each case.




Failure

LM04u.1.1 Message received for witness or victim with unknown witness

Unique Identifier.

Note: A unique identifier of a deleted witness or victim is

accepted if the message relates to the police rejecting a deletion

made by the CPS.

BE30

LM04u.1.2 Message received containing no Offence Identifiers for an

offence not known to CMS.

BE28

LM04u.1.3 Message received must contain a TypeOfPerson and

Victim/Wirtness Surname value if the message is not operating

in delete mode.

BE48



Ref Business Rule

LM04u.2.1 Witness or victim updated exists on the case and has not been deleted by CMS


The following table indicates when an LM04u message can be sent:

Ref Source Trigger

LM04u.3.1 Police Existing witness or victim updated in pre-charge or charge case by Police.

LM04u.3.2 Police Existing witness or victim deleted by Police

LM04u.3.3 Police Police reject a CPS update made to contact information on the non police

witness

LM04u.3.4 Police Police reject a CPS deletion of a witness or victim




110

6.8.7 Data


diagrams.

Figure 31 : The structure of the LM04u New Witness logical message.




111

Figure 32 : The structure of the UpdatedPerson element within the

LM04u New Witness logical message.




112

The UpdatedPerson structure is identical to the LM04 - New Witness or

Victim message‟s Person structure with the exception of the following three

new fields:

VersionNumber which is used to help the CPS and Police synchronise

their views of the victim/witness. This use of this is explained further in

Appendix H.4 and H.5.

Reason which provides the reason for

o Updating contact information on a non-police witness (update

mode, when contact details have been modified)

o Deleting a witness or victim (delete mode)

o Rejecting an update of contact information on a non-police

witness (update rejection mode)

o Rejecting deletion of a witness or victim (delete rejection mode)

Type of Reason which captures the type of reason as outlined in the

Reason description above taking one of the values Contact Info Update,

Deletion, Update Rejected, Deletion Rejected respectively.

A reason will not be provided for updating non contact information on a

witness or victim. If the message is used for any other purpose as listed

above then the Reason and TypeOfReason fields are mandatory.

In terms of witness updates as discussed in 5.1.7.2.1 the following data

items carried in the LM04u (and WM01u) under the UpdatedPerson node

are considered contact data:

Any data carried in ContactDetails with the exception of DXAddress and

ContactNumber where TypeOfNumber = „Other‟.

Any data carried in AlternateContact.ContactDetails as above.

Any data carried in AlternateContact.Name.Title / GivenName /

FamilyName.

Any data carried in PersonClassification where ClassificationType =

StatusInformation and ClassificationCode = NoDirectContact.




113

6.9 WM01u - Updated Witness or Victim

6.9.1 Description

This message is similar to the LM04u received from the police. The WM01u

message is sent by CPS to the police and allows

The CPS to send updates for an existing witness or victim on the

case providing it does not relate to a police witness8. Section

5.1.7.2.1 describes the exchange of witness updates between the

police and CPS (update mode).

The CPS to indicate a witness or victim deletion as described in

section 5.1.7.2.2 (delete mode).

The CPS to reject updates to contact information of non-police

witnesses provided by CPS on the WM01u message as described in

5.1.7.2.1 (update rejection mode).

The CPS to reject a deletion of a witness or victim provided by CPS

on the WM01u message as described in section 5.1.7.2.2 (delete

rejection mode).

The message must always contain the URN of the case the person belongs to

along with the unique identifier of the person and their current version

number. The message will be rejected if a witness or victim with the unique

identifier does not exist on the case with the exception of it relates to the

CPS rejecting a deletion of a witness or victim. In this instance, the witness

would have previously existed (prior to its deletion) on the case.

Further, the message will contain the full details of the witness or victim as

it stands unless it relates to the witness or victim deletion variant stated in

the 2nd

bullet above in which case only the Unique Identifier of the witness

or victim, their current version number and the reason for the deletion will

be provided. This message will not include victim-offence links.


than one witness or victim is to be updated, a separate instance of this

message must be sent for each of those witnesses.



6.9.3 Constraints

Constraint Value

8 The WM01u message is not sent to the police for updates of a police witness on CMS.




114

Constraint Value

Sender Compass CMS


Must be sent after Case Registered on police system and witness added to

case on police system. A unique identifier of a deleted

witness or victim is accepted if the message relates to the

CPS rejecting a deletion made by the police

Must be sent before Case finalisation on police system. WMS finalisation on

CMS.


How often As many times as required. Once for each relevant update

on CMS.




Failure

WM01u.1.1 Message received for witness or victim with unknown witness

Unique Identifier.

Note: A unique identifier of a deleted witness or victim is

accepted if the message relates to the CPS rejecting a deletion

made by the police

BE30

WM01u.1.2 Message received must contain a TypeOfPerson and

Victim/Wirtness Surname value if the message is not operating

in delete mode.

BE48



Ref Business Rule

WM01u.2.

1

Witness or victim updated exists on the case and has not been deleted by the police

WM01u.2.

2

Witness or victim updated has an External Unique Id.


The following table indicates when a WM01u message can be sent:

Ref Source Trigger

WM01u.3

.1

CPS Existing witness or victim updated in pre-charge or charge case by CPS.

WM01u.3

.2

CPS Existing witness or victim deleted by CPS

WM01u.3

.3

CPS CPS reject a police update made to contact information on the non police

witness




115

Ref Source Trigger

WM01u.3

.4

CPS CPS reject a police deletion of a witness or victim

6.9.7 Data


diagrams.

Figure 25 : The structure of the WM01u New Witness logical message.

The UpdatedPerson structure is the same as that in the LM04u. Like the

WM01 the OffenceId part of the victim element would never be populated

and CMS would also only use the PersonClassification structure for an

alternate contact to identify Welsh as their preferred language or provide a

value for their ethnicity, gender, religion/belief or disability. The

Witness.Rank/WarrantCardID values are only provided back if initially

supplied by the police and stored in CMS; CMS won‟t alter these at all.




116

6.10 LM05 - New Witness Statement

6.10.1 Description

This message allows a new witness statement to be added to an existing

witness. The message must contain the unique identifier of the witness who

made the statement, witness statement metadata and optionally an electronic

document representing the statement itself.

The unique identifier supplied for the witness links the statement to that

witness. The witness statement metadata is given a unique identifier in the

message that can be used to reference the statement from elsewhere. If an

electronic document representing the typed statement is provided, this

document is given a unique identifier of its own, and within the same

message the witness statement metadata references the document identifier.

The message can only be sent if the witness who made the statement was

added to the case and has had its UniqueId shared between the police system

and CMS. This would be the case if the witness was added to the police

system and notified to CMS via an LM04 or was added to CMS and notified

to the police via a WM01. If CMS contains multiple instances of the same

witness with identical Unique Ids (due to a case being split and re-merged)

then the witness statement will be linked to each instance of the duplicated

witness. If this happens it is a matter for CPS to resolve how the duplicate

witnesses will be managed, typically by deleting one of them.

The message can contain information for only one statement. If more than

one statement is to be added, a separate instance of this message must be

sent for each of those statements.

When this message contains an electronic document, the restrictions on

document handling described in [GPMS] will apply.


The v1 TypeOfDocument field has been dropped and the information it used

to provide now sent via the general classification structure, allowing the set

of known document types to be easily modified in the future. Note: at

present the document type is the only reason why the structure is on the

message though its presence does of course allow statements to be classified

in other ways in the future should the need to do so emerge.

The Attached Document can now also be a URL to the physical location of a

document instead of an actual binary of the file. This is included for future

expansion but isn‟t intended to be used at the outset of the TWIF rollout.

Whilst the v2 ExISS interface will now allow a variety of scanned document

formats to be transmitted, any witness statements in the LM05 must be in an

editable format, i.e. be of types *.doc, *.docx, *.rtf and *.txt.

.




117

6.10.3 Constraints

Constraint Value



Must be sent after Message LM04 - New Witness OR

Message WM01 - New Witness or Victim (containing

witness information for the witness who made this

statement). i.e. Witness must be known by both systems by

the same unique id.

Must be sent before Case finalisation on CMS, unless case was subject to asset

recovery or conditional cautions.


How often Once for each statement. As many times as required for a

witness and, therefore, a case.




Failure

LM05.1.1 Message received for Statement with Unique Identifier is not

already in use on the case as specified by the PTI-URN

BE43

LM05.1.2 Message received for a Witness (as specified by the Witness Unique

Identifier) that exists on the Case as specified by the PTI-URN

BE7

LM05.1.3 If message contains an attached document, it must contain a binary

representation of the actual document.

BE33

LM05.1.4 If message contains an attached document, it must be in an editable

format.

BE34

LM05.1.5 If message contains an attached document then the type of that

document must be declared using the DocumentClassification

structure.

BE36



Ref Business Rule


LM05.2.2 Each statement must be identified by a unique identifier at case level.

LM05.2.3 A statement can only be sent for a witness that has been previously sent as an LM04

message or received as a WM01 Message.






118

Ref Source Trigger

LM05.3.1 Police New Witness statement added to Police System.

6.10.7 Data


diagram:

Figure 33 : The structure of the LM05 New Witness Statement logical

message.




119

Figure 34 : The structure of the AttachedDocument Element used by

the LM05 New Witness Statement logical message.

The DocumentClassification expands to the General Classification Structure

shown in Appendix D. The ExternalFileLocation is included to illustrate

how a pointer to a physical file stored elsewhere can be provided but the

structure of this element is expected to change in the future pending work

being conducted by NPIA concerning sharing data in document/evidential

repositories between CJOs.




120

6.11 LM06 - New Exhibit

6.11.1 Description

This message allows a new exhibit to be added to a case. The message must

contain the URN of the case to which the exhibit is to be added and the

exhibit details. The exhibit message can optionally include an electronic

document (for example a ROTI) or the location details of the document and

login credentials if it stored at an external location. Note: Like the LM05

this is included here for future capability and it not intended to be used at the

outset of the TWIF rollout.

The unique identifier supplied for the defendant links the exhibit to that

defendant. The exhibit metadata is given a unique identifier in the message

that can be used to reference the exhibit from elsewhere. If an electronic

document (representing a ROTI, for example) is provided, this document is

given a unique identifier of its own, and within the same message both the

exhibit metadata and defendant references the document identifier.

The message must also include a unique identifier for the exhibit. The

message will be rejected if an exhibit already exists with the unique

identifier provided.

The message can contain information for only one exhibit. If more than one

exhibit is to be added, a separate instance of this message must be sent for

each of those exhibits.

As this message may contain an electronic document, the restrictions on

document handling described in [GPMS] will apply. Like v1, any attached

electronic document can be any of the types supported by the interface as a

whole which means any of these formats: *.doc, *.docx, *.txt, *.rtf, *.pdf,

*.jpg/jpeg.


The file within the LM06 has acquired an optional Exhibit Classification

structure as described in Appendix D to provide more flexibility in how

exhibits can be categorised in the future. The Attached Exhibit can now also

be a URL to the physical location of a file instead of an actual binary of the

file, though as stated above at present this data will be ignored if supplied.

The ItemName field has been increased from 50 to 4000 characters to align

it with CMS and allow the police to provide a fuller description of the

exhibit.

6.11.3 Constraints

Constraint Value



Must be sent after Any message that causes case registration, or manual case

registration




121

Constraint Value

Must be sent before Case finalisation on CMS, unless case was subject to asset



How often Once for each exhibit. As many times as required for a

case.




Failure

LM06.1.1 Message received for Exhibit with Unique Identifier that is not


BE44

LM06.1.2 If message contains an attached document, it must contain a binary

representation of the actual document.

BE33

LM06.1.3 If message contains an attached document then the type of that

document must be declared using the DocumentClassification

structure.

BE36



Ref Business Rule


LM06.2.2 Each exhibit must be identified by a unique identifier at case level.





Ref Source Trigger

LM06.3.1 Police New Exhibit added to Police System.

6.11.7 Data


diagram:




122

Figure 35 : The structure of the LM06 New Exhibit logical message.

The AttachedDocument element is the same as that for the LM05 message.

The ExhibitClassification element uses the Classification structure described

in Appendix D.5. The PersonProducingItem expands to the same name

structure for the LM01 in Figure 12




123

6.12 LM07 - New Case Document

6.12.1 Description

This message either allows an electronic document to be attached to a case

or allows the location details of the document and login credentials to be

supplied, if the document is stored at an external location. Again, like the

LM05, this latter capability is provided for future use and will not be used at

the outset of the TWIF rollout.

It provides an alternative to the existing email interface to CMS (although

this message will never trigger registration). The document carried by this

message will be accompanied by data describing that document, such as the

type of document (e.g. MG5) and a meaningful title.

The message must contain the URN of the case that the document is to be

attached to, the document itself, and metadata associated with the document.

With respect to charge cases it is not intended that this message will be used

to send typed witness statements or ROTIs, although this will not be

prevented. Messages LM05 - New Witness Statement and LM06 - New

Exhibit allow these to be sent with structured data specific to those

documents. If local practices require forces to submit statements and ROTIs

via an LM07 then this should be agreed and documented in the IBA between

that force and its CPS area. The LM07 is expected though to be used to send

scanned witness statements and other evidential material at the pre-charge

stage.

As this message contains an electronic document, the restrictions on

document handling described in [GPMS] will apply.


The v1 TypeOfDocument field has been dropped and the information it used

to provide now sent via the general classification structure, allowing the set

of known document types to be easily modified in the future. This set has

been increased from that in v1 to handle various new types of document

including, amongst others, pre-charge evidential material.

Note: at present the document type is the only reason why the structure is on

the message though its presence does of course allow documents to be

classified in other ways in the future should the need to do so emerge.

The Attached Document can now also be a URL to the physical location of a

document instead of an actual binary of the file, though for TWIF rollout it

will still be necessary to provide an attached binary file. The URL is present

to support future capability, not-with-standing the comment following

Figure 34.

In v2 the LM07 can take a wider range of document formats including the

*.doc, *.rtf and *.txt supported under v1, but also now extended to include




124

*.docx (native Word 2007/2010), *.pdf and the scanned image format

*.jpg/jpeg.

It should be noted that CMS also holds configuration data regarding which

police forces it permits the receipt of each document format from. While

version 2 of the interface supports the file types listed above, CMS may still

reject incoming messages of these types if the configuration data it holds

does not allow a police force to send a document in that particular format.

6.12.3 Constraints

Constraint Value

Sender Police IT System / Compass CMS

Recipient Compass CMS / Police IT System


registration

Must be sent before Case Finalisation on CMS, unless case was subject to asset



How often As many times as required for a case.




Failure

LM07.1.1 Message received for Document with Unique Identifier is not


BE45

LM07.1.2 Message received for a known document type BE10

LM07.1.3 Message contains a binary representation of the actual document. BE33

LM07.1.4 The type of the document must be declared using the

DocumentClassification structure.

BE36



Ref Business Rule

LM07.2.1 This message can be sent from the Police to CMS or from CMS to the Police.

LM07.2.2 Each document must be identified by a unique identifier at case level.

LM07.2.3 This message can only be sent against a case which already exists on CMS or police

systems, either through manual or electronic registration.

LM07.2.3 Where this message is sent from CMS, it cannot be done so before receipt of a previous

electronic message from the Police for this case




125



Ref Source Trigger

LM07.3.1 Police New Case Document added to Police System and dispatched as an LM07

message.

LM07.3.2 CMS New Case Document added to CMS System and dispatched as an LM07

message.

6.12.7 Data


diagram:

Figure 36 : The structure of the LM07 New Case Document logical

message.

The AttachedDocument element is the same as that shown in the LM05

message




126

6.13 LM08 - Full File Sent Indication

6.13.1 Description

This message indicates that the police have submitted the full case file. It

includes the URN of the case for which the full file has been submitted, but

does not carry any case data itself. It is expected that all of the data

constituting the full file will already have been sent before this message is

sent.

It is only valid to send this message once for a case. If on the first receipt of

the message the reviewing lawyer determines that the file is incomplete or

inadequate in some way, CMS will continue to consider the full electronic

file as received for the case. Resolving issues with the state of the file will

remain a manual process between the CPS and Police (although material can

continue to be sent using the other electronic messages).


The LM08 message has not changed between version 1 and version 2.

6.13.3 Constraints

Constraint Value




registration

Must be sent before Case finalisation on CMS


How often At most once per case




Failure

LM08.1.1 Case for which message is received is not marked as having

received the Full File

BE9



Ref Business Rule





127

Ref Business Rule





Ref Source Trigger

LM08.3.1 Police When the Police have sent the full file to the CPS

6.13.7 Data


diagram:

Figure 37 : The structure of the LM08 Full File Sent Indication logical

message




128

6.14 DM01 - Updated Defendant

6.14.1 Description

This message allows the CPS to send updates to an existing defendant on the

case to the police. This message will work in the same way as the LM03

message described in section 6.5, except that it is sent from the CPS to the

Police.

The message must contain the URN of the case the defendant belongs to

along with the unique identifier of the defendant. The message will be

rejected if a defendant with the unique identifier does not exist on the case.

The message can contain information for only one defendant. If more than

one defendant is to be updated, a separate instance of this message must be

sent for each of those defendants.



6.14.3 Constraints

Constraint Value

Sender Compass CMS


Must be sent after Case Registered in CMS and defendant added to case in

CMS

Must be sent before Case finalisation on either system


How often As many times as required for each defendant.




Failure



Ref Business Rule

DM01.2.1 This message can only be sent from CMS to the Police.

DM01.2.2 This message can only be sent against a case which already exists on the Police IT System

and contains the defendant to be updated, (i.e. the ASN and UniqueId are known to CMS).




129

Ref Business Rule

DM01.2.3 This message cannot be sent for dummy defendants created in support of pre-charge early

legal advice cases.


The following table indicates when an DM01 message can be sent:

Ref Source Trigger

DM01.3.1 CMS Existing suspect/defendant updated in pre-charge or charge case on

CMS/WMS, except when doing so because of receipt of an LM03.

6.14.7 Data

The structure of the DM01 logical message is the same as the LM03 logical

message, displayed in section 6.5.7 with the following exceptions:

Within the UpdatedCMSDefendant Structure the ASN element is

absent;

Within the PersonDefendant structure the following elements are

absent:

PNC Id

Initiated By

Police Remand Status

Bail Date

Bail Conditions

Aliases

These seven data items are all mastered in Police systems and whilst some

of them can be updated in CMS it is not appropriate for CMS to send their

updated values back to the Police as police systems hold the definitive

values for them.

Like the LM03, all items in the DM01 will be populated with the values of

the defendant at the time the update occurred, regardless of whether any

individual item was actually updated or not. Note: Whilst the DXAddress is

included as part of the ContactDetails it will not be populated by CMS.

Lastly, CMS maintains information on whether a defendant is marked as a

Seriously Dangerous Offender. The police can initially supply this

information on CM01, LM01, LM02 or LM03 messages via the




130

PersonClassification but have indicated they have no need to be notified of

when it changes on CMS. Hence regardless of how the defendant‟s

Seriously Dangerous Offender details are set or updated in CMS the DM01

will never contain any values for the PersonClassification‟s

StatusInformation.SeriouslyDangerousOffender.




131

6.15 CM01: Pre-charge Decision Request

6.15.1 Description

This message contains the pre-charge decision request sent by the police, it

corresponds with the sections that the police complete on the MG3 or

MG3A.

The message may contain one or more suspects. If a suspect is supplied then

proposed charges can optionally be supplied for that suspect in a structured

form.

It may also contain references to witness statements, interview records,

videos etc. These will not create entities (e.g. a new statement will not be

created) in CMS but will appear as a text to support the duty prosecutor

making the charging decision.

The message will also contain the supervising officer and the officer

completing the request for a decision. The type of contact required between

the duty prosecutor and the police or the expected nature of the consultation

may also be provided e.g. Face-to-Face, Written and Telephone.

The officer may also decide to send an overview of the case although this

may be supplied in person and is therefore optional. A date by which the

pre-charge decision is required will be provided in the message. Case

monitoring codes may also be included in the CM01 message.

A suspect may have this message sent in many times for them, person

suspect details will include defendant monitoring flags, police remand

status, how the arrest process was initiated and bail details. If a suspect has

previously been the subject of a CM01, all subsequent CM01s should use

the same UniqueId to refer to the existing suspect.

The police may indicate in the message other cases which should be co-

considered with the current case during the pre-charge decision consultation.


This message is new at version 2 of the interface.

6.15.3 Constraints

Constraint Value



Must be sent after (No Constraint)

Must be sent before Case Finalisation on Compass CMS unless the finalised

case has conditionally cautioned suspects matching those

on the CM01or a new suspect is to be created on CMS off

the CM01.

Can cause registration on

Compass CMS

Yes




132

Constraint Value

How often As many times as required.




Failure

CM01.1.1 Message referenced an unknown CPS Unit. Unit ID = [ID]. BE18

CM01.1.2 Case already finalised.

Message not supported for this case in Finalised State or Pending Admin

Finalisation state as at least one of the following conditions are not met

by the case

The finalised case has at least one defendant whose last pre-charge

decision, excluding any of „not given for this suspect‟, was either

„D - Conditional Caution‟ or „D5 - CC non-compliance - continue -

variance‟. It does not matter if the consultation in which this last

decision was given was completed or not. The defendant satisfying

the above condition must be present in the message.

The case has been finalised with at least one defendant given either

of the finalisation codes „Finalised Pre-charge - Conditional

Caution‟ or Finalised Pre-charge - CC Non-compliance - Continue

with Variation‟. The defendant satisfying the above condition must

be present in the message.

A new defendant is to be added to the case through this message.

BE5

CM01.1.3 Associated URN for a co-consideration association type relates to a case

with a URN that is recognised.

BW01 -

Warning

Message

CM01.1.4 The Particulars provided consist of the Address component only. BE46

CM01.1.5 If present, the ProposedCharge UniqueID must be unique within the

message and an Offence must not exist on the case or a Proposed Charge

on an open consultation on the case with the same UniqueId as the

ProposedCharge UniqueID in the message.

BE17



Ref Business Rule

CM01.2.1 This message can only be sent from the Police to Compass CMS.


The following table indicates when an CM01 message can be sent:

Ref Source Trigger

CM01.3.1 Police Police require new consultation from the CPS. This may be for suspects




133

Ref Source Trigger

on a new case, a new suspect on an existing case or an existing suspect on

an existing case.

6.15.7 Data

Figure 38 - The high level structure for the CM01 message representing

a pre-charge decision request.




134

The PTI-URN, CPSUnit and CaseClassification are the same as seen in the

LM01.

Figure 39 - The structure of the suspect in the CM01 message.




135

The ASN, AccusedOrganisation, DefenceSolicitor and the whole

DefendantPersonStructure that forms the AccusedPerson are the same as

seen in the LM01.

Figure 40 - The structure of the MaterialProvided element.

The MaterialClassification is provided as an instance of the general

classification structure and used to annotate the type of material that is being

provided with values shown as per Appendix D.13. MaterialDate should

always be set unless the material being provided is „previous

convictions/disposals‟ for which a single date is not applicable.




136

Figure 41 - The structure of the OfficerSupervising element.

The PoliceOfficerStructure is defined as a common component used for both

the OfficerSupervising and the OfficerCompleting (and police witnesses in

other messages). Within this component though, for the OfficerSupervising

CMS only uses values in the GivenName and FamilyName fields of the

Name sub-structure and the Rank and ShoulderNumber fields. Data in any

of the other elements is ignored.




137

Figure 42 - The structure of the OfficerCompleting element

For the OfficerCompleting CMS uses values in the GivenName and

FamilyName fields of the Name sub-structure, the address (postal and DX),

email and non home phone numbers in the ContactDetails substructure and

the Rank, Station and ShoulderNumber fields. Data in any of the other

elements is ignored. The comment on rank data in 6.3.2 applies here for

OfficerCompleting and OfficerSupervising as well.

The Station element is ignored by CMS if CMS‟s internal configuration data

identifies a default police station associated with the combination of the

registering CPS unit and the police unit identified by the 3rd

and 4th

characters of the URN. If no such default is available the Station field is

used, if provided, and data in ContactDetails associated with it.




138

Figure 43 - The structure of the CaseOutlineItem element

The CaseOutlineHeading is provided as an instance of the general

classification structure and is used to annotate the type of case outline

component that is being provided with values shown as per Appendix D.6. It

is preferable to supply the case outline broken down by the headings shown

in D.6 to support streamlined processing, However if a force‟s system is

unable to do this the case outline text should all be placed under the

„summary of key evidence‟ heading.




139

Figure 44 - The structure of the ProposedCharge element

The Particulars element is used by the police to inform CPS of where an

offence was committed and its content would ultimately be used to help

generate the particulars text of the offence, especially in populating the

substitution fields in the particulars template text pertaining to location

aspects. Many of the PNLD offence particulars templates contain named

substitution fields like <TOWNSHIP>, <LOCATION>, <AIRPORT>,

<SHIP>, <ADDRESS> etc. The TWIF Working Group discussed the idea

of the police providing such details where relevant on the proposed charges

via the ParticularsClassification and CMS using them to automatically pre-

populate associated parts of the particulars text if the proposed charges were

promoted to advised charges. However, the combination of CPS Duty

Prosecutors not being mandated to provide the particulars and widescale

variance in the type of location data police systems could provide meant this




140

capability has not been developed in CMS. However the

ParticularsClassification element remains in the schema to potentially

support this in the future. Indeed the „Particulars‟ and

„ParticularsClassification‟ elements are named such, rather than using the

more specific „location‟ to accommodate even more future capability where,

for given types of proposed charge, the police could supply any supporting

ancillary data necessary to create the full particulars, e.g. values for the

template substitution fields <GOODS>, <DRUG> etc.

However at present, the business process is that the police will simply

provide only offence location data and do this via a standard postal address

and a duty prosecutor would manually derive any substitution values in the

particulars template from this and the wider circumstances of case text as

necessary. If the police do provide ParticularsClassification data it would be

ignored at present in CMS. The ParticularsClassification provided is an

instance of the general classification structure and is used to annotate the

type of Location that is being provided with values shown as per Appendix

D.7.

The police should only include instances of ProposedCharge for any given

suspect in the CM01 that are relevant to the current consultation request for

that suspect. For the first consultation for a suspect all proposed charges

should be given. For second and subsequent consultations arising because a

suspect was given a H, I or J decision, the original proposed charges should

be repeated with the same UniqueId if they remain relevant and further ones

added if necessary. The original proposed charges with the same UniqueId

should also be re-used as necessary (along with any new proposed charges)

where a conditional caution has been breached and the police are seeking a

possible subsequent prosecution.

For second and subsequent consultations arising where a suspect was given

an A, B or B2 decision only new proposed charges should be included

relevant to the additional circumstances of the case that require the further

consultation.




141

6.16 CM02: Pre-charge Decision Response

6.16.1 Description

This message contains the pre-charge decision response sent by the CPS, it

corresponds with the sections that the CPS complete on the MG3(S) or

MG3A(S).

The message will contain details of the pre-charge consultation case

analysis, decision (e.g. A: Charge + request full file) and an adjudication on

the police proposed charges. If the decision is “K: NFA - Evidential” then

the duty prosecutor must supply an Evidential code. If the decision is either:

“C: Simple Caution”, “D: Conditional Caution”, “D5: Conditional Caution

non compliance”, “E: Reprimand”, “F: Final Warning”, “G: TIC” or “L:

NFA - Public Interest” then the duty prosecutor must supply a Public

Interest code.

If the duty prosecutor decides that the suspect should be charged then they

must supply at least one CJS Offence Code for the suspect.

The duty prosecutor may also supply an action plan for the police to

implement and a follow up date on which the CPS will review the case and

associated action plan.

If the suspect decision is one of the following A, B, B2, D, D2, K, L and G

an adjudication decision will be provided for all of the suspect‟s proposed

charges available at the time of the PCD consultation, for all other suspect

decisions C, D5, E, F, H, I, J, M and Z, no adjudication decision would be

provided in the CM02 for the suspect‟s proposed charge(s).

This message may be sent many times for a suspect.



6.16.3 Constraints

Constraint Value

Sender Compass CMS


Must be sent after Pre-charge Decision Consultation completion on Compass

CMS where ASN for the suspect exists on Compass CMS.

Must be sent before Case Finalisation on Police IT System


Police IT System

No

How often As many times as required for a suspect.






142


Failure



Ref Business Rule

CM02.2.1 This message can only be sent from Compass CMS to the Police.


The following table indicates when a CM02 message can be sent:

Ref Source Trigger

CM02.3.1 CMS CPS Prosecutor completes a pre-charge decision consultation for a suspect

that has an Arrest Summons Number (ASN) assigned and the decision for

the suspect was either anything other than „not given for this suspect‟ or

the suspects has only ever been previously given the decision „not given

for this suspect‟.

CM02.3.2 CMS A suspect on CMS is updated to have a previously blank Arrest Summons

Number (ASN) set and has already been the subject of a pre-charge

decision.

6.16.7 Data

Figure 45 - The structure of the CM02 pre-charge decision response

message.




143

Figure 46 - The structure for the Pre-Charge Decision within the CM02.

The ActionPlan expands into the ActionPlanStructure exactly as seen in the

FM02 (see Figure 55 and Figure 56) and its field are described there

The DutyProsecutor expands to the usual Name structure of Data Standards

4.3 as shown in Figure 12 of the LM01 though only the GivenName and

FamilyName will be provided. Where a CM02 is produced from a




144

consultation created by a structured MG3 form9 processed in CMS, if the

lawyer who filled out the form advised a pre-charge split it is important to

understand that the workflow in CMS is such that the split instructions will

be provided as free text in the ActionPoint field in this case and police

systems must not attempt to parse this to perform an automated split in the

manner they may do where the split instructions are received in structured

format in the SplitMergeInformation part of the action plan.

The PCDConsultationId is a CMS generated unique integer that identifies

every consultation performed in CMS. Its purpose in the CM02 is further

explained in Appendix E, Consultation Matching, but essentially allows the

police to determine if they have previously received the consultation

information against which the suspect decision is being declared.

9 Consultations will usually be captured electronically in CMS by duty prosecutors typing

information directly into CMS and currently all consultations done in daytime hours are

done as such. Out of hours nightime consultations are done by CPSD who follow a process

of filling out a structured MG3 word document and submitting this by email to CMS

whereupon the consultation data is captured. Consultations performed this way will be

subject to the free text split instruction. There is an initiative in CPS for more CPSD staff to

directly use CMS for nightime consultations but the extent to which this is adopted

nationally is subject to ongoing debate; and there will always be occasions when nightime

consultations have to be performed when CMS is unavailable and these will use the

structured MG3, so the need to support the free text split instruction cannot be designed out

of the business process at this stage. Further, as part of the modernising charging initiative

CPS are moving to a daytime call centre model for lawyers to dispense pre-charge advice

and whilst these lawyers are expected to use CMS there may be rare occasions where this is

not possible and the backup plan is for them to also use the CPSD structured MG3 form.




145

Figure 47 -The structure of the Case Analysis part of the CM02

The CaseAnalysisItem expands into a CaseAnalysisText and

CaseAnalysisHeading allowing the Duty Prosecutor to provide narrative on

many named aspects of the consultation. Each narrative is carried in the

CaseAnalysisText which is categorised by the CaseAnalysisHeading which

in turn expands to the general classification structure allowing different

analysis categories to be added in the future, see Appendix D.8. Readers of

previous versions of this BPD will be aware that where the

CaseAnalysisHeading identified the provision of Evidential Criteria, Public

Interest, Mode of Trial or ECHR narrative then two further fields

(CaseAnalysisToggle and ModeOfTrial) used to exist that indicated with

structured data how the duty prosecutor felt the analysis category was

satisfied. This data is no longer captured in CMS and the

CaseAnalysisToggle and ModeOfTrial fields have been removed. The

structured information they used to provide must now be inferred from the

Duty Prosecutor‟s free text narrative held in the CaseAnalysisText field.




146

Figure 48 -The structure of the Suspect Decision part of the CM02

The GeneralDecision and ReasonCode both expand to the general

classification structure.

The ConditionalCaution structure, shown below, will be populated if the

GeneralDecision for the suspect was D = Conditional Caution or D5 =

Conditional Caution Non Compliance; Continue with variation.

The OffenceDecision structure, shown below, will be populated if the

GeneralDecision for the suspect was A, B or B2.

The AdjudicationDecision structure, shown below, will be populated if the

GeneralDecision for the suspect was A, B, B2, D, D2, K, L or G.

Figure 49 -The structure of the Conditional Caution part of the CM02

When a suspect decision of „D‟ has been given the SpecificCondition,

ConditionEndDate and ComplianceConfirmation fields will be populated

with the details of the condition that formed the caution. Note: CMS is

currently specified to capture as structured data a single end date, condition

description and compliance statement for a conditional caution and so only

one instance of the ConditionalCaution element would be returned in the

CM02. CMS may be enhanced in the future to capture multiple end dates,

conditions and compliance statements as structured data and when this

happens then multiple instances of the ConditionalCaution element could

then be returned in the CM02. In advance of this though, if multiple

conditions are set as part of the caution the convention in CMS is to enter

the statements of those conditions and their associated end dates all as free

text in a single field which is written to the SpecificCondition element in the




147

CM02 and the ConditionEndDate would reflect the latest date across those

different end dates. To help police isolate the individual conditions within

the single SpecificCondition field a facility exists in CMS to insert a break

line of 20 dash characters in the free text between conditions. So a multiple

condition caution may be presented as follows:

SpecificCondition 1/2/2011 : Write letter of apology to Mrs Smith

--------------------

20/3/2012 : Stay away from skate park after 6pm

ConditionEndDate 20/3/2012

ComplianceConfirmation Check with Mrs Smith that she received the letter and

make sure park CCTV doesn‟t show defendant.

However CMS does not enforce this convention for multiple conditions and

the extent to which it is used will depend on local arrangements as reflected

in the IBA between a force and its CPS area and the diligence of duty

prosecutors, so some form of manual intervention may always be necessary

when assessing the contents of the SpecificConditions field.

When a suspect decision of „D5‟ has been given all fields of the

ConditionalCaution element will be populated where values exists in CMS

but only for those conditions within the caution that have undergone some

change, either in the nature of the condition or the end date of the condition.

The EndDateVaried and ConditionVaried fields will show if either or both

of these have varied. Note: Similar to above, CMS is currently specified to

only allow variation to be declared on a single original condition and so only

one instance of the ConditionalCaution element will be present in the CM02.

If in the future multiple initial conditions are supported then CMS would

also support declaring variation against any of these allowing multiple

instances of the ConditionalCaution element to be returned in the CM02.

Similar to above though, in advance of this happening if multiple conditions

are varied then each variation will be included in the SpecifCondition field

and separated by a line of 20 dashes.

In autumn 2009 the TWIF working group discussed the possibility of

recording which conditions apply to which offences the conditional caution

is delivered for but in March 2010 advised that this was no longer likely to

be necessary. There are thus no further plans to build the ability to capture

this information in CMS and send it back on the CM02.




148

Figure 50 - The structure of the Offence Decision part of the CM02

Where a suspect has been given a prosecution decision the OffenceDecision

contains details on the charges the Duty Prosecutor is advising the police to

charge the suspect with. Where the advised charge has been based10 on a

proposed charge sent on a CM01 the UniqueId will be set to same value as

the UniqueId of that proposed charge. If the advised charge is not based on a

proposed charge the UniqueId will be a CMS generated value new to the

police system.

The CJSCode is the same as seen in the LM01. The Particulars expands into

the structure exactly as seen in the CM01. Where offences have been created

directly from proposed charges via an adjudication decision of Accept,

Accept with Variation or Replace the Particulars will reflect the detail

(original or amended) that was supplied in the CM01. If the Duty Prosecutor

10 Based in the sense that the proposed charge had been given an adjudication decision of

Accept or Accept with Variation.




149

has added new charges not originally proposed then the Particulars would

only be populated at his discretion. The OffenceWording contains the

particulars text of the advised charge but again this is provided at the Duty

Prosecutor‟s discretion. The extent to which this discretionary data is

provided would be subject to agreement between a force and its CPS area as

recorded in their IBA.

Figure 51 - The structure of the Adjudication Decision part of the

CM02

The AdjudicationDecision element is populated depending on the

SuspectDecision.GeneralDecision as stated in section 3.4.3.4.

The ProposedUniqueId always matches the UniqueId values sent in on the

CM01 and allows the police to know which of their original proposed

charges is being adjudicated on.

When an AdjudicationClassification of „Replace‟ is provided for a

SuspectDecision.GeneralDecision of A, B or B2 the ReplacementUniqueId

will have the value of the UniqueId of the OffenceDecision data that

represents the Duty Prosecutor‟s replacement charge, otherwise it will

always be blank.

When an AdjudicationClassification of „Replace‟ is provided for a

SuspectDecision.GeneralDecision of D the ReplacementCJSCode,

ReplacementParticulars, ReplacementFromDate and ReplacementToDate

are provided to show the details of the replacement offence the suspect

should be conditionally cautioned with, otherwise they are always blank.

When an AdjudicationClassification of „Reject‟ is provided for a

SuspectDecision.GeneralDecision of A, B, B2 or D the RejectionReason




150

field will contain free text details of why the proposed charge was rejected

as part of the prosecution or conditional caution.

The ReplacementCJSCode is the same as CJSCode as seen in the LM01.

The AdjudicationClassification expands to the general classification

structure and is used to annotate the type of adjudication decision that is

being provided with values shown as per Appendix D.11. The

ReplacementParticulars is the same as seen in OffenceDecision.Particulars

elsewhere in the CM02.




151

6.17 CM03: Charge Information

6.17.1 Description

This message contains the actual charges put to the suspect. It contains the

full offence text and the date of the suspect‟s first hearing.

This message will not create a defendant nor will it register a case.



6.17.3 Constraints

Constraint Value



Must be sent after Charges have been put to the defendant. The URN and

defendant already exist on Compass CMS. At least one

CM01 has been sent to Compass CMS for the URN and

defendant combination, such that a unique identifier for the

defendant exists on Compass CMS.

Must be sent before Case Finalisation on Compass CMS


Compass CMS

No

How often As many times as required.




Failure

CM03.1.1 Offence Details Not Reconciled11.

The CJS code, CJS code inchoate qualifier (if applicable) and mode of

trial category of the matching charge on CMS must be the same as those

provided on the incoming CM03

- for coded offences on CMS

- for uncoded offences on CMS, where an uncoded offence is provided

in the incoming CM03.

The category of the matching charge on CMS must be the same as that

provided on the incoming CM03.

BE26

11 This checks that where an advised charge has been sent on a CM02 under a given

UniqueId then if the police return the UniqueId on a CM03 the PNLD charge code should

not have been wrongly tampered with. If the police wish to add new non-advised charges of

their own they would do so via new UniqueId that CMS hadn‟t seen before.




152



Ref Business Rule

CM03.2.1 This message can only be sent from the Police to CMS.


The following table indicates when an CM03 message can be sent:

Ref Source Trigger

CM03.3.1 Police Charges have been put to the defendant and a CM01 has previously been

sent to Compass CMS for the URN and defendant combination.

6.17.7 Data

Figure 52 - The structure of the charge information sent back as a

CM03 from the police to the CPS.




153

Figure 53 -The structure of the Defendant part of the CM03

The, Offence and NextHearing are the same as seen in the LM01.




154

6.18 FM01 - Case Status

6.18.1 Description

This message will allow CMS to indicate to the police system a change in

the monitoring codes or the status of a case, particularly in terms of

finalisation. This would be useful if a case had been finalised and needs to

be reactivated, or a live case was finalised or a case was put under appeal.

The police would use the change in case status as an alert to re-appraise the

work they are currently doing on the case or may have to do in the future.

This message can be sent many times for a case.



6.18.3 Constraints

Constraint Value

Sender Compass CMS



registration

Must be sent before Case Deleted or Destroyed From CMS





Ref Business Rules Response on

Failure

FM01.1.1



Ref Business Rule

FM01.2.1 This message can only be sent from CMS to the Police.

FM01.2.2 Defendants must have a Unique Id to be included on a message informing that a case has

been placed under appeal, i.e. the defendant must be known to police systems.




155


The following table indicates when an FM01 message can be sent:

Ref Source Trigger

FM01.3.1 CMS The CMS Case status changes in a way that affects the Police decision to

send further messages:

FM01.3.1.1 CMS When a case is finalised, excluding administrative finalisation on CMS

due to 3 months passing from last recorded outcome of ASD, SNS or

WTN.

FM01.3.1.2 CMS When a case is reactivated.

FM01.3.1.3 CMS When a case is put under appeal.

FM01.3.1.4 CMS/WMS When the monitoring codes are updated on a case.

6.18.7 Data


diagram:




156

Figure 54 : The structure of the FM01 CaseStatus logical message.

The CaseClassification element uses the Classification structure described in

Appendix D.2. In the message it is used to convey the monitoring codes set

on the case. The structure will be populated only when a change to the case

monitoring codes has occurred. This would always happen when the

CaseStatus is set to MON but could also happen when CaseStatus is FIN or

LIV if the monitoring codes were changed at the point the case was finalised

or reactivated. If monitoring codes are changed the structure will be

populated with every known monitoring code with an accompanying

true/false Boolean value indicating if the code is set or not on the case. In

the extreme case, if the change is to remove the last monitoring code on the




157

case then the structure will contain every monitoring code and all their

values will be false.

The Appellant, TypeOfAppeal and DefendantId items are only populated

when CaseStatus is set to APP and provide further detailed information on

how the case is being put under appeal. Note: In the unlikely event that a

case is placed under appeal but none of the defendants to which the appeal

applies are known to the police (in that they do not have a police Unique Id

assigned to them) the FM01 message will still be created but the

DefendantId element will not be populated.




158

6.19 FM02 - New Action Plan

6.19.1 Description

This message will allow the CPS to inform the police how the case file

should be prepared which includes instructions for starting, modifying or

stopping the file build. This message also informs the police that a merge

(pre and post-charge) or post-charge split has been undertaken on CMS and

now needs to be done on the police side.



6.19.3 Constraints

Constraint Value

Sender Compass CMS



registration

Must be sent before Case Finalised in CMS






Failure

FM02.1.1 All URNs specified in a merge case instruction are known to the police

system

BE35



Ref Business Rule

FM02.2.1 This message can only be sent from CMS to the Police.






159

Ref Source Trigger

FM02.3.1 CMS The CMS Case has been split and an action plan must be sent to the Police

to instruct them of the split.

FM02.3.2 CMS One or more CMS Cases have been merged and an action plan must be

sent to the Police to instruct them of the merge.

FM02.3.3 CMS CPS requests that the police stop, start or modify the case file build.

6.19.7 Data


diagram:

Figure 55 : The structure of the FM02 NewActionPlan logical message.

The ActionPlan element comprises an ActionPlanItem and

ActionPlanFollowUpDate field pair, which is the same for the CM02, and

an ActionPlanRequestor which is specific to the FM02 and expands to the

usual Name structure of Data Standards 4.3 as shown in Figure 12 of the

LM01. In a similar manner to the DutyProsecutor field on the CM02, only

the GivenName and FamilyName fields in ActionPlanRequestor will ever be

set in CMS and provide the identity of the user logged onto CMS who

created the action plan. The ActionPlanItem is depicted below:




160

Figure 56 : The structure of the ActionPlanItem

The fields in the action plan are used as described below, depending on

whether the action plan is present in a CM02 or FM02.

Field When used in CM02 When used in FM02

ActionPlanFollowUpDate The optional overall

action date usually

provided on the MG3.

Blank

ActionEntryDate

When the action was created on CMS.

ActionDate When the duty prosecutor would like the police to address

the action.




161

ActionPoint If ActionType = Pre-charge

Split and the pre-charge

consultation this message

pertains to was created by

CPS Direct or Daytime Direct

staff filling out an MG3 form

then the ActionPoint field will

contain unstructured freetext

instructions on how the case

should be split.

If however the consultation

was created by CPS staff

entering information manually

into CMS then the

ActionPoint field will be

blank and the split instructions

will be present in a structured

format in the

SpliMergeInformation field.

If ActionType = Action Plan

then the ActionPoint field is

always blank.

Explanation for when

ActionType = Stop File

Build OR

Description of contested

issues for when

ActionType = Start File

Build OR Modify File

Build

ActionType Pre-charge Split

Action Plan

Post-charge Split

Merge

Start File Build

Stop File Build

Modify File Build

FileOptions ActionType =

Pre-charge Split

ActionType =

Post-charge Split OR

Merge OR

Stop File Build

Blank

ActionType =

Action Plan

ActionType =

Start File Build OR

Modify File Build

A set of instructions coded via FileOptionClassification (see

Appendix D.14), typically requests for particular

information, the CPS want the police to perform along with

any optional supporting narrative in the FileOptionText

field.

DefendantId Optional list of defendants the action applies to12.

SplitMergeInformation See below after Figure 57.

If the action specified is relating to a split or a merge then the following

information will be further supplied in the message:

12 Note: CMS allows its users to specify a single defendant or all defendants when creating

action plan items. If the „all defendants‟ option is chosen then all defendants on the case

with a police originated UniqueId are included in the FM02. In the future CMS might be

enhanced to allow a subset of the case defendants to be specified for an action plan item,

and these could be accommodated in the existing FM02 structure shown above.




162

Figure 57 : The structure of the SplitMergeInformation.

This structure supports both the post-charge split and merge instructions on

the FM02 and also the pre-charge split instructions detailed in the action

plan on the CM02.

Field When used in CM02 When used in FM02

URNToMerge Always blank Only set when ActionType =

Merge, otherwise blank.

When set, URNToMerge

then contains the list of other

URNs that are to be merged

with the case the message is

being sent to.

Split Only set when ActionType =

Pre-charge Split.

NewCaseId then provides an

ascending sequence number

starting at 1 for each new

case the police should create

for which the police assign

the URNs.

SplitCaseURN is not used.

Only set when ActionType =

Post-charge Split

SplitCaseURN will hold the

fully qualified URN and its

split suffix of each new child

case generated on CMS, i.e.

04BE1234509/3.

NewCaseId is not used.




163

DefChargeInformation For both pre- and post-charge splits the identity of the

suspects/defendants and their charges to move to each split

child case are provided on the DefChargeInformation item. If

charges are not specified for a suspect, then the suspect and all

their associated charges should be moved to the split case.

Note 1: The FM02 message will contain no pseudo ChargeId

for a Not Yet Charged suspect that has been split.

Note 2: For a Pre-Charge Split only the defendants and charges

associated with the new cases will be included. Defendants and

charges that are to remain on the original case are excluded.

Note 3: If a suspect/defendant who is the subject of a split is

held on CMS but is not known to the police in that they have

no police Unique id held on CMS for them (this would happen

for suspects/defendants registered manually on CMS) then they

will still beincluded in the message but referenced with a

pseudo DefendantId of 0. This way, the police are still made

aware of the need to split the case and what URNs should be

assigned to the child cases but it will be left as a manual

exercise for them to liaise with CPS and determine the identity

of the suspect/defendant to substitute for the placeholder value

0.

The SplitCaseURN and URNToMerge are the same as the base PITURN

structure.




164

6.20 FM03 - Split/Merge Synchronisation

6.20.1 Description

This message will allow the police to indicate to CMS that in pre- and post-

charge scenarios their merge of cases has completed or in a post-charge that

the police have completed splitting a case. Receipt of the message allows

CMS to know that the police have completed re-organising their split/merge

cases and that messages can start to freely flow between those cases on

either side.



6.20.3 Constraints

Constraint Value




registration

Must be sent before Case deleted or destroyed from CMS






Failure



Ref Business Rule

FM02.2.1 This message can only be sent from the Police to the CMS.



Ref Source Trigger

FM03.3.1 Police The merging of two or more cases completes on the Police IT System. The




165

Ref Source Trigger

FM03 is sent from the primary URN chosen in the merge.

FM03.3.2 Police The splitting of a case into two or more child cases completes on the

Police IT System. An FM03 is sent as the last message from the original

un-split police case.

6.20.7 Data


diagram:

Figure 58 : The structure of the FM03 SplitMergeSynchronisation

logical message.




166

6.21 Business Responses

In response to receipt of a message, Compass CMS or the police IT system

will send a message to indicate whether the message was accepted and

processed successfully or rejected. The logical messages can be rejected in

some circumstances as described in the sections above. This rejection will

be dealt with using a business response message. The error responses are

listed in below.

This document does not attempt to define how responses will be dealt with

by the system receiving the response.

A single message structure will be used for all responses whether they

indicate success or failure. The structure of this message and the data it

contains are shown in the diagram:

Figure 59 : The structure of the business response message

The Response Code and Text items describe the response itself.

The following table lists all the CMS Police Error messages. The Business

Error ID is the logical identifier of the Error message and is included for

backward compatibility. The status code is the actual error code returned in

the response code of the response message.

Business

Error ID

Status

Code

Type Text Available

at V1

Available

at V2

1 Success Success Y Y

BE1 120 Case already registered

A case with this

URN has already

been registered.

Y Y

BE2 200 Unknown case Message relates

to a case with a

URN that is

unknown to the

CPS/Police13. This

may have resulted

from the case not

being registered

yet or because

the CPS/Police

have manually

deleted the case.

Y Y

13 Delete as appropriate. When the response is sent from the CMS this will say „CPS‟ and

when sent from a police system is will say „Police‟.




167

Business

Error ID

Status

Code

Type Text Available

at V1

Available

at V2

BE3 170 Unknown court Unknown court.

Court ID = [ID]. Y Y

BE5 180 Case already finalised

Case has been

finalised by the

CPS. Additional

messages not

allowed.

Y Y

BE6 210 Message not supported on advice case

This type of

message is not

supported on an

Advice case.

Y N

BE7 220 Unknown witness - cannot add statement

Cannot add

witness statement

to the case as it

relates to an

unknown witness.

Witness unique ID

specified = [ID].

This may have

resulted from the

CPS deleting the

witness from the

case.”

Y Y

BE8 (Not used)

BE9 260 Case already flagged as Full File

Sent

Case already

flagged as full

file sent. This

message can only

be sent once for

a case.

Y Y

BE10 230 Invalid document type

Invalid document

type. Only the

following

document types

are supported by

the CMS:

[doctypes].

Y Y

BE11 190 Case has been split or merged

Case has been

split or merged

by the CPS. It is

not possible to

add a new

defendant in this

situation.

Y N

BE12 270 Case has been split Case has been

split by the CPS.

The message must

be sent to one of

the split child

cases instead.

N Y

BE13 110 Duplicate victim Each entity on a

case must have a

unique ID

associated with

it. An attempt to

Y N




168

Business

Error ID

Status

Code

Type Text Available

at V1

Available

at V2

add a

[entitytype] with

unique id [ID]

did not conform

to this rule.

BE14 110 Duplicate Charge Each entity on a

case must have a

unique ID

associated with

it. An attempt to

add a

[entitytype] with

unique id [ID]

did not conform

to this rule.

Y Y

BE15 (Not used)

BE16 321 Unknown Suspect/ Defendant

An error occurred

on processing

this message.

Unknown

defendant.

N Y

BE17 110 Entity already exists

Each entity on a

case must have a

unique ID

associated with

it. An attempt to

add a

[entitytype] with

unique id [ID]

did not conform

to this rule.

Y Y

BE18 130 Unknown CPS Unit Message

referenced an

unknown CPS Unit.

Unit ID = [ID].

Y Y

BE19 150 Missing Charge Details

Offence must be

supplied for

defendant on a

non-Pre Charge

Decision case.

Defendant unique

ID = [ID].

Y N

BE20 140 Missing Defendant At least one

defendant must be

supplied for a

Charge case.

Y N

BE21 160 Offences supplied on Advice Case

Offences must not

be supplied for

defendants on an

Advice case.

Defendant unique

ID = [ID].

Y N

BE22 322 Message not supported on non-

charge case

This type of

message is not

supported on a

N Y




169

Business

Error ID

Status

Code

Type Text Available

at V1

Available

at V2

non-charge case.

BE23 323 Message supports cases in one of the

following states Live, Finalised or Pending Admin

Finalisation

This type of

message is not

supported for

cases in the

following state

Deleted/

Destroyed /

Pending Deletion

/ Split-Merge in

Process /

Superseded*

(* deleted as

appropriate).

N Y

BE24 (Not used)

BE25 (Not used)

BE26 324

Offence Details Not Reconciled.

The CJS code,

inchoate

qualifier and

mode of trial

category of the

matching charge

on CMS must be

the same as that

provided on the

incoming message.

N Y

BE27 (Not used)

BE28 325 Unknown Offence The Unique Id of

the Offence must

exist on the

case. Offence

unique ID

specified = [ID].

Y Y

BE29 (Not used)

BE30 326 Unknown witness - cannot update

witness

Cannot apply

witness update to

the case as it

relates to an

unknown witness.

Witness unique ID

specified = [ID].

This may have

resulted from the

CPS deleting the

witness from the

case.

Note: A unique

identifier of a

deleted witness

or victim is

accepted if the

message relates

to the police

rejecting a

N Y




170

Business

Error ID

Status

Code

Type Text Available

at V1

Available

at V2

deletion made by

the CPS.

BE31 (Not used)

BE32 327 Unknown Associated Case

Associated URN

relates to a case

with a URN that

is unknown to the

CPS. This may

have resulted

from the case not

being registered

yet or because

the CPS have

manually deleted

the case.

N Y

BE33 328 No Document Attached

A document must

be supplied in a

binary format. A

link to an

external file is

not currently

supported.

N Y

BE34 329 Non editable document format

A document must

be supplied in an

editable format;

either

doc,docx,rtf,txt

N Y

BE35 330 Unknown Merge Case

The case with URN

=[URN] does not

exist on the

police system so

the merge action

requested cannot

be completed.

N Y

BE36 331 Document Type not stated

A document must

be supplied with

a declaration of

what type of

document it is.

N Y

BE37 333 Inappropriate Classification

[level]

classification

has been provided

at the level of a

[level]

(Note : [level]s

will not be the

same as one

another but will

be one of Case,

Person, Document,

Exhibit,

Organisation,

Pre-Charge,

Material, File

Option)

N Y




171

Business

Error ID

Status

Code

Type Text Available

at V1

Available

at V2

BE38 334 Duplicate Classification

Multiple values

of

[Classification

Type],

[Classification

Code],

[Classification

Value] have been

provided.

N Y

BE39 332 Version of EXISS interface not supported

The EXISS version

of the message

must match the

version of the

EXISS interface

supported by the

Police Force.

N Y

BE40 335 Unsupported Classification

The combination

of <Type>, <Code>

and <Value> is

not supported.

N Y

BE41 110 Duplicate Defendant

Each entity on a

case must have a

unique ID

associated with

it. An attempt to

add a

[entitytype] with

unique id [ID]

did not conform

to this rule.

Y Y

BE42 110 Duplicate Witness Each entity on a

case must have a

unique ID

associated with

it. An attempt to

add a

[entitytype] with

unique id [ID]

did not conform

to this rule.

Y Y

BE43 110 Duplicate Witness Statement

Each entity on a

case must have a

unique ID

associated with

it. An attempt

to add a

[entitytype]

with unique id

[ID] did not

conform to this

rule.

Y Y

BE44 110 Duplicate Exhibit Each entity on a

case must have a

unique ID

associated with

it. An attempt

Y Y




172

Business

Error ID

Status

Code

Type Text Available

at V1

Available

at V2

to add a

[entitytype]

with unique id

[ID] did not

conform to this

rule.

BE45 110 Duplicate Case Document

Each entity on a

case must have a

unique ID

associated with

it. An attempt to

add a

[entitytype] with

unique id [ID]

did not conform

to this rule.

Y Y

BE46 338 Address not provided for Particulars

Address not

provided for

Particulars

N Y

BE47 339 Victim Witness Mismatch

The TypeOfPerson

<Type> is

inconsistent with

the provision of

supporting data

in the <VicWit>

node.

N Y

BE48 340 Witness Update Data Missing

When not

indicating a

victim/witness

deletion the

message must

provide a value

for

<TypeOfPerson>

and <Name> *

(* delete as

appropriate)

N Y

BE49 342 Split Case Message de-sequenced

Message received

for split case

without prior

FM03 confirmation

of split.

N Y

BE100 100 Invalid Message Invalid Message.

The structure of

the message did

not match what

was expected.

Message returned

from validation

process

<message>.

Y Y

BW01 337 Unknown Associated Case

for Co-Consideration

The following

URN(s) <URN, URN,

URN…>, were not

available on CMS

to allow the

N Y




173

Business

Error ID

Status

Code

Type Text Available

at V1

Available

at V2

generation of co-

consideration

linkages between

cases.

BW02 336 Person Classification Not

Applicable

The Person

Classification

<Type>, <Code>

must be

applicable to the

type of person it

is applied to.

N Y

BW03 343 Association Inappropriate

Co-consideration

linkages are not

valid for this

message and have

been ignored

N Y

Table 3.1: Business Responses




174

7 Data Protection, Protective Marking and Security

The provisions of the Data Protection Act 1998 cover the contents of

messages sent between systems using this interface. This includes,

Police Systems modified to use this interface.

Compass Case Management System

Criminal Justice System Exchange (CJSE)

Before using the interface a CPS Area and Police Force will be required to

enter into an Interchange and Benefits Agreement (IBA). A Template

Agreement will be provided by a National Deployment Team, in a form

approved by the Two Way Interface Project Board. The IBA will include the

appropriate legal disclaimers, obligations under the Data Protection Act,

protective marking issues, discharging of responsibilities by each party, etc.

Such agreement will include provisions dealing with the following,

The Police and the CPS will maintain a Data Protection Policy. All data

used in the interface will be handled in accordance with that policy and

with each agency‟s Data protection Notification Scheme.

Data entered onto Compass CMS belongs to CPS.

Data entered onto the police IT systems belongs to the police.

The interface will permit the automatic registration of cases on Compass

CMS. This will be allowed, without verification of the data. Any items

of Core Data missing at registration will result in tasks being created to

retrieve those core details.

Any material errors in the data sent, detected by either the police or the

CPS will be notified to the other as soon as possible.

Other than is permitted by the exchange of updated information by the

messages defined in this interface any updates to previously recorded

data on Compass CMS will not take place until such time as a CPS

Compass CMS User confirms that the changes to the data are to be

made.

Data received from the police may only be disclosed to those classes of

persons/organisations noted in the CPS Data protection Notification. It is

intended that in appropriate circumstances, as part of the ordinary

business of the CPS such data may be disclosed to,

o Defendants in Person.

o Solicitors acting for Defendants.

o Solicitors acting for Third Parties.




175

o Solicitors acting for the CPS.

o Victims and Witnesses.

o Persons/Organisations providing support services for Victims

and Witnesses.

o Counsel for the Defendant.

o Counsel for the Prosecution.

o Magistrates Courts.

o Crown Courts.

o Appeal Courts.

o Probation Service.

o Prison Service.

o Youth Offending Teams.

o Home Office.

o Others with a legitimate interest in the data.

No material protectively marked higher than RESTRICTED is to be

exchanged. Police IT systems using this interface and Compass CMS

willoperate at a security level of RESTRICTED

The Police and CPS must take appropriate steps to ensure that;

o The data is not used for purposes other than those which

currently exist for paper exchanges.

o RESTRICTED Information received must not be replied to or

forwarded to others outside of the Police or CPS over an insecure

channel, e.g. using standard unencrypted Internet mail. It can

however be sent by post or fax.

o The information received must be handled securely; electronic

and printed copies of the information must be protected from

unauthorised access.

o Users are required to handle protectively marked information in

accordance with the policy in force for their agency.

The IBA will specify how Security breaches are to be dealt with.

Examples of Security Breaches include, but are not limited to the

following,




176

o Any data loss whatsoever.

o Sending information protectively marked CONFIDENTIAL or

above.

o Any incident in which the confidentiality of data is jeopardised.

o Any accidental or deliberate unauthorised destruction of

information.

o Any deliberate denial of access to authorised users.

o Any misuse of data.

o Any theft of information or any item of equipment.

o The means of reporting any security breach through the

organisations normal channels will be specified. Users must be

made aware of their responsibility for security and the process in

case of breach.




177

8 Detailed Data Assumptions

This section provides further detail relating to the data referenced in the

Logical Message Model.

8.1 Message Contents

This group of tables describes the contents of each message. The structures

and types listed in this section can be cross-referenced with items in the

Data Dictionary table in the next section.

CM01

Element Type Description

BaseItemStructure BaseItemStructure The unique Id of the item within

the business message and the case

Identifier

CPSUnit OrganisationLocationCodeStructure The CPS unit that will take

responsibility for the case

OperationName Text The name of any police operation

associated with this case

CaseClassification ClassificationStructure Contains Case Level Attributes

such as monitoring codes

Suspect SuspectStructure Contains details about the

suspect(s)

MaterialProvided MaterialStructure Contains details of material(s)

associated with the case

CaseOutlineItem Container Contains the CaseOutlineHeading

(which is of type

ClassificationStructure) and

CaseOutlineText (String of length

1-32500).

PCDPoliceContactDetails Container Contains the OfficerCompleting

and OfficerSupervising elements

AssociatedCases CaseAssociationsStructure Contains identifiers of associated

cases and description of

association

PCDRequestDate Date Date the pre-charge decision

request was made to the CPS

PCDDecisionRequiredByDate Date Date the pre-charge decision is

required by the Police

Contact ContactType Type of contact required between

the duty prosecutor and the police

CM02




Identifier

Decision PreChargeDecisionStructure Contains details of the pre-charge

decision(s)




178

CM03




Identifier

Defendant Defendant Contains unique Id of the

defendant, details of their

offence(s) and of the next hearing.

DM01




Identifier

PersonDefendant BaseDefendantPersonStructure Details of the defendant (if the

defendant is a person)

OrganisationDefendant DefendantOrganisationStructure Details of the defendant (if the

defendant is an organisation) VersionNumber Int Version number of these details for

the defendant

FM01




Identifier

CaseStatus CaseStatusType Indicates the status of the case

ConditionalCautionDefendantExists Boolean Flag indicating if any defendant on

the case has been subject to a

conditional caution at any pre-

charge decision response

OpenConfiscationExists Boolean Flag indicating if the case in

question has any open confiscation

orders

Classification ClassificationStructure The classification flags associated

with the case

DefendantId UniqueIdType List of Defendant identifiers

Appellant AppellantType “Appellant” value selected from

Register Appeal screen

TypeOfAppeal AppealType

FM02




Identifier

ActionPlan Container

Details of each action plan item, a

follow up date for the plan and the

identity of the CPS requestor.

Contains an ActionPlanStructure

type and ActionPlanRequestor




179

(which is of type

PersonNameStructure).

FM03




Identifier

LM01




Identifier

CPSUnit OrganisationLocationCodeStructure The CPS unit that will take

responsibility for the case

OperationName Text The name of any police operation

associated with this case

CaseClassification ClassificationStructure Contains case level attributes such

as monitoring codes

Defendant DefendantStructure Contains details about the

defendant(s)

OfficerInCase PoliceOfficerStructure Contains details about the officer

in case

AssociatedCase CaseAssociationsStructure Contains identifier of an associated

case and description of association

LM02




Identifier

Defendant DefendantStructure Contains details of the defendant

and charge information

LM03




Identifier

PersonDefendant DefendantPersonStructure Details of the defendant (if the

defendant is a person)

InitiatedBy InitiatedByType Whether initiated by Charge,

Summons or Postal Requisition

OrganisationDefendant DefendatOrganisationStructure Details of the defendant (if the

defendant is an organisation)

ASN ASNStructure Arrest summons number

VersionNumber Int Version number of these details for

the defendant




180

LM04




Identifier

Person BaseWitnessVictimStructure Contains details of an individual

who is a victim, a witness, or a

victim and a witness

LM04u




Identifier

UpdatedPerson BaseWitnessVictimUpdateStructure Contains updated details of an

individual who is a victim, a

witness, or a victim and a witness.

Includes a reason and reason type

field which can be used to indicate

the person should be deleted

LM05




Identifier

WitnessStatement WitnessStatement Contains WitnessId and Statement

AttachedDocument DocumentInformationStructure Describes an electronic witness

statement.

LM06




Identifier

DefendantId UniqueIdType The unique identifier for the

defendant

Exhibit Exhibit Contains exhibit details (ExhibitId,

ItemName, Reference,

PersonProducingItem,

ExhibitClassification)

AttachedDocument DocumentInformationStructure Describes an electronic document

LM07




Identifier

AttachedDocument DocumentInformationStructure Represents the electronic

document to attach to the case




181

LM08




Identifier

WM01




Identifier

Person BaseWitnessVictimStructure Contains details of an individual

who is a victim, a witness, or a

victim and a witness

WM01u




Identifier

UpdatedPerson BaseWitnessVictimUpdateStructure Contains updated details of an

existing individual who is a victim,

a witness, or a victim and a

witness. Includes a reason and

reason type field which can be

used to indicate the person should

be deleted

8.2 Data Dictionary

The data dictionary describes all the simple types and can be cross-

referenced with the Message Contents tables in the previous section.

Data Dictionary Item Type Allowable values / Complex Type Content Description

ActionPlanStructure Container Complex Type comprising: A container for the Action

Plan information. ActionPlanItem may

contain multiple

ActionPlanItems.

Data Item Type

ActionPlanItem ActionPlanItemStructure

ActionPlanFollowUpDate Date

ActionPlanItemStructure Container Complex Type comprising: A container for the Action

Plan Item information. May contain multiple

DefendantID and

FileOptions elements.

Data Item Type

ActionEntryDate Date

ActionType ActionType

ActionPoint Text (1-8000)

ActionDate Date

DefendantID UniqueIdType

FileOptions FileOptionsStructure

SplitMergeInformation SplitMergeInformationStructure

ActionType Text Pre-charge Split Permitted action types

Post-charge Split




182

Merge

Action Plan

Start File Build

Stop File Build

Modify File Build

AddressStructure Container Complex Type comprising: The address of the person

coded in simple format. The

address complies with the CJS Data Standard

Data Item Type

AddressLine(s) (2-8) Text (1-100)

Postcode Text (1-8)

Country Text (1-100)

AddressUpdateStructure Container Complex Type comprising: The address of the person

coded in simple format. The

address complies with the CJS Data Standard. This

differs to AddressStructure

by making all elements optional.

Data Item Type

AddressLine(s) (0-8) Text (1-100)

Postcode Text (1-8)

Country Text (1-100)

AdjudicationDecisionStructure Container Complex Type comprising: Holds details of an Adjudication Decision.

Data Item Type

ProposedUniqueId UniqueIdType

AdjuducationClassification ClassificationStructure

ReplacementUniqueId UniqueIdType

ReplacementCJSCode OffenceCodeStructure

ReplacementParticulars OffenceParticularsStructure

ReplacementFromDate Date

ReplacementToDate Date

RejectionReason Text (100)

AdviceMethod Text Face to Face Valid Advice Method

options Telephone (CPS Direct)

Telephone (Daytime Direct)

Written

Electronic14

AlternateContactStructure Container Complex Type comprising: The base information for an

alternate contact Data Item Type

Base BasePersonStructure

AppropriateContact Boolean

RelationshipTo Text (1-255)

AppealType Text Conviction Allowable Appeal Type

values Sentence

Higher Court Appeals

AppellantType Text Defendant Allowable Appellant values

CPS

ASNSequenceNumberType Text [0-9]{3} As per ExISSr1. The

sequence number of this

offence within the defendant's ASN instance.

ASNStructure Container Complex Type comprising: Describes the ASN, Arrest

14 It is the „electronic‟ method that indicates CPS did a consultation without direct police

contact. As of v1.0 of this BPD, this is effectively a dormant capability in the interface

since no live TWIF forces have expressed a desire to formally support such a business

process just yet. Even so, CMS allows this value to be captured but when sent on a CM02 it

is arbitrarily re-mapped to „Telephone (Daytime Direct)‟. This re-mapping will only be

removed when all live forces agree to start accepting the value.




183

Data Item Type Summons Number without

it's sequence number. Year TwoDigitYearType

Organisation OrganisationIdentifierType

Force ForceIdentifierType

Unit Text ([0-9A-Z]{2})

System Text ([0-9A-Z]{2})

Number Text ([0-9]{11})

CheckCharacter CheckDigitType

AssociationType Text Pre-charge Split Types of case associations

Co-consideration

BaseChargeStructure Container Complex Type comprising: Holds information relating

to a charge specified in a

pre-charge decision Data Item Type

OffenceID UniqueIdType

CJSCode OffenceCodeStructure

Description Text (1-600)

Category OffenceCategoryType

FromDate Date

ToDate Date

BaseItemStructure Container Complex Type comprising: The base item from which all others are derived. This

item is abstract and cannot

be used within an instance document

Data Item Type

ItemId UniqueIdType

PTIURN PTIURNStructure

BasePersonDefendantStructure Container Complex Type comprising: The base structure for a

person defendant Data Item Type


DateOfBirth Date

Nationality NationalityType

Occupation OccupationDescriptionType

ParentGuardian BasePersonStructure

BasePersonStructure Container Complex Type comprising: The base person type from

which all other are inherited Data Item Type

UniqueId UniqueIdType

Name PersonNameStructure

ContactDetails ContactDetailsUpdateStructure

PersonClassification ClassificationStructure

BaseWitnessVictimStructure Container Complex Type comprising: The base information for a

victim/witness Data Item Type


DateOfBirth Date

TypeOfPerson PersonType

AlternateContact AlternateContactStructure

Witness WitnessStructure

Victim VictimStructure

BaseWitnessVictimUpdateStructure Container Complex Type comprising: The base update

information for a victim/witness

Data Item Type

UpdatedWitnessVictim UpdatedWitnessVictim

CaseAssociationsStructure Container Complex Type comprising: Holds information about

associated cases Data Item Type

AssociatedPTI-URN PTIURNStructure

AssociationType AssociationType

CaseStatusType Text FIN Allowable case status

values (FIN=Finalised, LIV=Live, APP=Appeal,

MON=Monitoring Codes

LIV

APP




184

MON Updated)

CheckDigitType Text [A-HJ-NP-RT-Z]{1} As per ExISSr1

ClassificationStructure Container Complex Type comprising: Generic Classification

structure to support all classification schemes

Data Item Type

ClassificationType Text

ClassificationCode Text

ClassificationValue ClassificationValue

ClassificationValue

Container Complex Type comprising of Holds values associated

with a classification Data Item Type

ClassificationValueFlag Boolean

ClassificationValueText Text (1-500)

ClassificationValueInteger Int

ClassificationValueEnumeration Text

ConditionalCautionVariationStruture Container Complex Type comprising: Holds information about

when and why a conditional caution has been varied

Data Item Type

ReasonForVarying Text (1-2000)

EndDateVaried Boolean

ConditionVaried Boolean

ContactDetailsStructure Container Complex Type comprising: The base contact

information for a party Data Item Type

Address AddressStructure

Number TelephoneNumberStructure

TypeOfNumber TelephoneNumberType

Email EmailAddressType

DXAddress TwifDXAddressStructure

ContactDetailsUpdateStructure Container Complex Type comprising: Holds updated contact

information for a party. Data Item Type


Number TelephoneNumberStructure

TypeOfNumber TelephoneNumberType

Email EmailAddressType

DXAddress TwifDXAddressStructure

ContactType Text Face-to-Face Enumeration containing

valid types of contact Written

Telephone

Electronic15

CPRStructure Container Complex Type comprising: Describes the CPR, Criminal Prosecution

Reference. Data Item Type

DefendantOffender DefendantOffender

OffenceCode OffenceCodeStructure

OffenceSequence ASNSequenceNumberType

DecisionStructure Container Complex Type comprising: Holds information about a

decision Data Item Type

SuspectId UniqueIdType

GeneralDecision ClassificationStructure

ReasonCode ClassificationStructure

ConditionalCaution PCDConditionalCautionStructure

OffenceDecision OffenceDecisionStructure

AdjucicationDecision AdjudicationDecisionStructure

15 It is the „electronic‟ method that signifies the police are happy for CPS to conduct the

consultation without direct discussion. As of v1.0 of this BPD, this is effectively a dormant

capability in the interface since no live TWIF forces have expressed a desire to formally

support such a business process just yet.




185

DefChargeInformationStructure Container Complex Type comprising: Links a defendant with 0-

many charges DefendantID UniqueIDType

ChargeID UniqueIDType

Defendant Container Complex Type comprising: This holds charge information for a PCD

defendant Data Item Type

DefendantId UniqueIdType

Offence OffenceStructure

NextHearing HearingStructure

DefendantOffender Container Complex Type comprising: This is similar to an ASN but caters for other

prosecutors Data Item Type

Year TwoDigitYearType

OrganisationUnit OrganisationLocationCodeStructure

Number Text([0-9]{11})

CheckDigit CheckDigitType

DefendantOrganisationStructure Container Complex Type comprising: The base information for a defendant, where the

defendant is an organisation Data Item Type


OrganisationName Text (1-255)

ContactDetails ContactDetailsStructure

OrganisationClassification ClassificationStructure

DefendantPersonStructure Container Complex Type comprising: The base information for a

defendant who is a person Data Item Type

Base BaseDefendantPersonStructure

PNCId PNCIdStructure

PoliceRemandStatus PoliceRemandStatusType

BailConditions Text (1-2000)

Alias PersonNameStructure

DefendantStructure Container Complex Type comprising: The base information for a

generic defendant. This can be an organisation or a

person

Data Item Type

PersonDefendant DefendantPersonStructure

OrganisationDefendant DefendantOrganisationStructure

ASN ASNStructure

Offence OffenceStructure

DefenceSolicitor DefenseSolicitorStructure

InitiatedBy InitiatedByType

NextHearing HearingStructure

DefenseSolicitorStructure Container Complex Type comprising: Holds information relating to a defense solicitor

Data Item Type


Firm Text (1-50)

CaseReference Text (1-30)

DeletedPersonStructure Container Complex Type comprising: Identifies the person to be

deleted Data Item Type


DeletionReason Text (1-500)

DocumentInformationStructure Container Complex Type comprising: Holds the information related to an attached

document or the location of

an electronic document

Data Item Type


Name Text (1-255)

FileName Text (1-255)

Document base64Binary

ExternalFileURL Text

Username Text

Password Text

DocumentClassification ClassificationStructure




186

EmailAddressType Text Text (1-255) As per Data Standards

EvidentialTest Text Early Consultation Valid Evidential Test

options Full Code Test

Investigative Advice

Threshold Test

Exhibit Container Complex Type comprising:

Data Item Type

ExhibitId UniqueIdType

ItemName Text (1-4000)

Reference Text (1-50)

PersonProducingItem PersonNameStructure

ExhibitClassification ClassificationStructure

FileOptionsStructure Container Complex Type comprising:

Data Item Type

FileOptionClassification ClassificationStructure

FileOptionText Text (0-2000)

FileOptionType Text All key witness statements (or copy of police notebooks in police charged cases) not provided with the initial file

Direction on how to modify or start the case file build

through prescribed codes. MG6 series (B;C;D;E) together with copies of FWIN, crime report,

relevant pocket notebooks, identification procedure booklets and investigation progression record (where available)

MG2 and supporting statement for any witness requiring special

measures

MG10 with availability for ALL witnesses

Victim Personal Statement

ROTI

MG16 and MOs for relevant convictions

Paper exhibits (3 copies plus 1 copy for each additional defendant)

Visually recorded evidence (3 copies plus 1 copy for each additional

defendant)

Medical evidence

Forensic evidence

Previous convictions for all prosecution witnesses

Other (specify)

ForceIdentifierType Text [0-9]{2} As per ExISSr1

HearingStructure Container Complex Type comprising: Base Hearing Structure

Data Item Type

CourtID OrganisationLocationCodeStructure

CourtRoom nonNegativeInteger

TypeOfCourt TargetCourtTypeList

DateAndTime DateTime

InitialConditionalCautionStructure Container Complex Type comprising: Describes an initial

conditional caution Date Item Type

SpecificCondition Text (1-2000)

ConditionDate Date

InitiatedBy Text Charge Method by which the pre-charge decision (PCD)

process was initiated. Summons

Postal Requisition

InputType Text Scanned Indicates whether a person

is avi victim, witness or both

Typed

InvestigationStageType Text Bail for Charging Decision Valid Investigation Stage

options Post Arrest

Post Bail for Further Enquiries

Post Interview

Pre Arrest

MaterialStructure Container Complex Type comprising: Holds information about

materials that may be Data Item Type




187

MaterialClassification ClassificationStructure attached to a case

MaterialSubject Text (1-500)

MaterialDate Date

SentElectronically Boolean

MaterialType Text Statement Valid Material Types

Interview Record

Forensic/Expert Evidence

Pocket Note Book/Incident Report Book

Police Incident Log

Video/Photographs

Previous Convictions/Disposals

Other

NationalityType Text Text (1-50) As per ExISSr1. The

nationality of an individual.

OccupationDescriptionType Text Text (1-54) As per Data Standards. The

occupation of an individual.

OffenceCategoryType Text Summary Only The category of offence as one of Summary Only,

Either Way or Indictable

Only.

Either Way

Indictable Only

OffenceCodeStructure Container Complex Type comprising: Describes the offence code.

An optional LiteralValue attribute allow the English

short Title of the offence to

be given. Qualifier may be one of A for attempting, B

for aid and abetting, C for

conspiracy or I for inciting.

Data Item Type

ActOrSource Text ([A-Z]{2})


CommonLawOffence Text (COML)

Reason Text ([0-9]{3})

Qualifier Text ([ABCI]{1})

OffenceDecisionStructure Container Complex Type comprising: Describes a charge decision made by the CPS

Date Item Type

Base BaseChargeStructure

OffenceWording Text (1-2000)

Particulars OffenceParticularsStructure

OffenceParticularsStructure Container Complex Type comprising: Describes the Particularas

of the offence. May consist of an address and one or

more

ParticularsClassifications, or just one or more

ParticularsClassifications. If

an address is provided, at least one of the

ParticularsClassifications must be “Township”.

Data Item Type


ParticularsClassification ClassificationStructure

OffenceStructure Container Complex Type comprising: Holds all information

relating to an offence for a

specific defendant Data Item Type


CPR CPRStructure

ASNSequenceNumber ASNSequenceNumberType

CJSCode OffenceCodeStructure

Description Text (1-120)

OffenceWording Text (1-2000)

Category OffenceCategoryType

ArrestDate Date

StartDate Date

EndDate Date

ChargeDate Date

OfficerSupervising Container Complext Type comprising:

Holds all information relating to a supervising




188

Data Item Type Police Officer

PoliceOfficerStructure PoliceOfficerStructure

Narrative Text (1-16000)

OrganisationIdentifierType Text [0-9ABCDEFG]{1} As per ExISSr1

OrganisationLocationCodeStructure Container Complex Type comprising: Describes the organisation

and location code. An

optional LiteralValue attribute allows the display

of the English name of the

Organisation/Location.

Data Item Type

TopLevel OrganisationIdentifierType

SecondLevel Text ([0-9A-Z]{2})

ThirdLevel Text ([0-9A-Z]{2})

BottomLevel Text ([0-9A-Z]{2})

PCDConditionalCautionStructure Container Complex Type comprising: Holds information about a conditional caution decision

Data Item Type

ConditionEndDate Date

ComplianceConfirmation Text (1-2000)

InitialConditionalCaution InitialConditionalCautionStructure

ConditionalCautionVariation ConditionalCautionVariationStructure

PCDPoliceContactDetails Container Complex Type comprising Holds contact information

for both officer completing

the PCD and the supervising officer

Data Item Type

Officer Completing PoliceOfficerStructure

OfficerSupervising OfficerSupervising

PersonNameStructure Container Complex Type comprising: The base information for a person‟s name. This is

commensurate with the CJS

Data Standard in using the same sub element names

and field sizes, however at

present the ordering of the given and family names is

not included. This is

because there is no support for this on the systems and

the requirements for such

support are ill (or not) defined

Data Item Type

Title Text (1-35)

GivenName Text (1-35)

FamilyName Text (1-35)

PersonNameUpdateStructure Container Complex Type comprising: The base person update type

from which all other are inherited

Data Item Type

Title Text (1-35)

GivenName Text (1-35)

FamilyName Text (1-35)

PersonType Text Victim Indicates whether a person

is a victim, witness or both Witness

VictimWitness

PNCIdStructure Container Complex Type comprising: Describes PNC (Police National Computer)

Identifiers. These are

normally Ids that are unique to a defendant and the same

between different cases.

Data Item Type

Year Text ([0-9]{4})

SerialNumber Text ([0-9]{7})

CheckCharacter CheckDigitType

PoliceOfficerStructure Container Complex Type comprising: The base information for a

police officer Data Item Type


Rank Text

Station Text (1-50)

ShoulderNumber Text (1-10)

PoliceRemandStatusType Text Custody Indicates the remand status

of the defendant while they are the responsibility of the

police i.e. prior to the first

hearing. The field will not normally be applicable

when the defendant is

summonsed

Conditional bail

Unconditional bail

Part 4 bail

Reported




189

PreChargeCaseAnalysisStructure Container Complex Type comprising: Holds details of pre-charge

case analysis. Allows

multiple case analysis items to be described.

Data Item Type

CaseAnalysisHeading ClassificationStructure

CaseAnalysisText Text (1-32767)

PreChargeDecisionStructure Container Complex Type comprising: Describes a complete pre-

charge decision Data Item Type

PCDConsultationID UniqueIdType

EvidentialTest EvidentialTest

CaseAnalysis PreChargeCaseAnalysisStructure

InvestigationStage InvestigationStageType

AdviceMethod AdviceMethod

SuspectDecision DecisionStructure

ActionPlan ActionPlanStructure

DutyProsecutor PersonNameStructure

PCDResponseDate Date

ProposedChargeStructure Container Complex Type comprising: Describes the charges the police suggest the suspect

should be charged with Data Item Type

Base BaseChargeStructure

Particulars OffenceParticularsStructure

PTIURNStructure Container Complex Type comprising: Describes the PTI-URN

(Pre Trials Issues group -

Unique Reference Number). This number is used as an

identifier for cases within

the police and CPS. The PTI-URN format is defined

within the Manual of

Guidance. This description extends that definition.

Where extensions are made

they are described in the comments for the element

Data Item Type

Force ForceIdentifierType

Unit Text ([0-9A-Z]{2})

Number Text ([0-9]{5})


Split PositiveInteger

ReasonType Text Update Rejected Enumeration contain valid

types of reason Contact Info Update

Deletion Rejected

Deletion

SplitMergeInformationStructure Container Complex Type comprising: Describes the split/merge.

Split and URNToMerge may contain multiple items.

Data Item Type

Split SplitStructure

URNToMerge PTIURNStructure

SplitStructure Container Complex Type comprising: Describes the contents of

the child case. Data Item Type

SplitCaseURN PTIURNStructure

NewCaseID PositiveInteger

DefChargeInformation DefChargeInformationStructure

Statement Container Complex Type comprising: Holds a witness statement

Data Item Type

StatementId UniqueIdType

StatementNumber int

StatementDate Date

SuspectStructure Container Complex Type comprising: Holds information relating to a suspect on a pre-charge

decision Data Item Type

AccusedPerson DefendantPersonStructure

AccusedOrganisation DefendantOrganisationStructure

DefenceSolicitor DefenseSolicitorStructure

ASN ASNStructure

ProposedCharge ProposedChargeStructure

SystemIdType Text Text (1-40) As per ExISSr1

TargetCourtTypeList Text Youth Court The type of court within

which a hearing is to be held, as per Data Standards

Magistrates Court




190

TelephoneNumberStructure Container Complex Type comprising: Describes an international

telephone number. This is

as described in the OeE UK Telephone Number type

from the GDSC

Data Item Type

TelCountryCode Text ([0-9]{1,3})

TelNationalNumber Text ([0-9 /-]{1,20})

TelExtensionNumber Text ([0-9]{1,6})

TelephoneNumberType Text home Enumeration containing valid telephone number

types work

mobile

fax

other

TransactionModeType Text live The transaction mode may be set to live for

transactions that should

update the live database and test for transactions that are

not to effect the live

database and are only being

sent to test the interface

test

TwifDXAddressStructure Container Complex Type Comprising Describes a Hayes DX

address Data Item Type

DXNumber Text (1-20)

Exchange Text (1-20)

MemberName Text (1-20)

TwoDigitYearType Text [0-9]{2} As per ExISSr1

UniqueIdType Text Text (1-40). Enforced as uppercase. Gives a unique Id to a number of elements

UpdatedWitnessVictim Container Complex Type comprising: Holds details of updated

values to a victim/witness. Data Item Type

Base BasePersonUpdateStructure

VersionNumber Int

TypeOfPerson PersonType

DateOfBirth Date

AlternateContact AlternateContactStructure

Witness WitnessStructure

Victim VictimStructure

Reason Text (1-2000)

TypeOfReason ReasonType

VictimStructure Container Complex Type comprising: Holds victim specific values to update

Data Item Type

OffenceId UniqueIdType

Dummy Text

WitnessStatement Container Complext Type comprising: Holds a witness statement

Data Item Type

WitnessId UniqueIdType

Statement Statement

WitnessStructure Container Complex Type comprising: Holds witness specific

values to add or update Data Item Type

Occupation OccupationDescriptionType

Rank Text

ShoulderNumber Text (1-10)

WarrantCardID Text (1-30)




191

8.3 Data

8.3.1 Classification Codes

CMS supports classification codes at both the case and suspect level. For

example, a case may be identified as a Child Abuse case through a flag

attached to the case; a suspect may be identified as a PPO through a flag

attached to the suspect.

Currently no standard exists for these codes but the Data Standards

Working Group are going to discuss standardising them. If a standard

is approved within a timeframe that permits them to be incorporated

into the messaging system then this standard will be adopted otherwise

a list of flags will be implemented similar to the ExISS interface.

8.3.2 Criminal Justice Organisational Unit (CJOU) Codes

CJOU Codes provide a method of uniquely identifying locations such as

court rooms and CPS units. A complete specification for the CJOU Codes

may be found in the CJIT Data Standards Catalogue.

CJOU Codes shall be used wherever practicable within the messages, in

particular, where courts for hearings need to be identified and the CPS unit

for the case needs to be identified.

8.3.3 Offence Codes

All offences in CMS must include a number of mandatory fields, of these a

number represent static data for the offence which is repeated in order to

support unknown, inchoate and local offences. The repeated and mandatory

static data is:

CJS Code, identifies the offence;

Category, offences have an associated mode of trial that is one of

summary, either-way or indictable-only. This information is key to the

calculation of custody time limits which work at the offence level;

Description, a short description of the offence;

Offence Wording, the full offence wording including particulars and

statement of offence for the offence;

Recordable, is the offence classed by the Home Office as “Recorded”16.

16 A 'crime recordable offence' - is an offence which MUST BE recorded as a conviction on the Police

National Computer (PNC), and includes:

any offence punishable with a term of imprisonment, AND




192

All CJOs are faced with the difficulties arising from offence codification

and non-coded offences such as byelaws. Compass makes use of CJS

offence codes and has data from PNLD and IBIS but does not generally

code byelaws.

When an offence is transmitted over the interface CMS will attempt to

match the offence code with one in the CMS database. If this is successful

then CMS will create a charge based on the offence code provided. If this is

unsuccessful then CMS will create a charge based on one of 3 generic

offence codes one each for summary, either-way and indictable-only. The

mode of trial therefore is mandatory for all offences which are transmitted

over the interface.

8.3.4 Reference Numbers

The standard use of the PTI URN will be adopted as the unique identifier for

a case. In the version 2 interface the PTI URN no longer indicates if the case

is an advice case as this is a legacy concept no longer supported in CMS.

Advice cases have been superseded as part of the statutory charging

programme. Also, the split suffix which was present in version 1 but unused

is retained but now has a formal use to support the post-charge splitting of

cases.

8.3.5 Creating or Updating Entities

If an entity, such as an offence or suspect, does not exist on CMS then it will

be created when details of it are received through the interface.

If an entity is found to exist already on CMS then it will be subject to

various degrees of updates depending on the type of entity and the

messages. Broadly speaking, for defendants the data on an LM03 will be

used to unconditionally update data on CMS. However the data on the

CM01 and CM03 will generally only be used to update data on CMS if it is

not currently defined and this applies to:

Suspect Name (both person and organisation suspects);

Suspect Contact Details;

Welsh Documents;

PNCID;

Date of Birth;

a number of non imprisonable offences have been specified by the Secretary of State in regulations as

being required to be recorded on the Police National Computer (PNC).




193

Gender;

Self Defined Ethnicity;

Nationality;

Occupation;

Aliases;

Initiated By;

Status Information;

Parent Guardian;

A similar approach is used in CMS when updating witness data off an

LM04u in that incoming data in the message is only used where the

corresponding item is not set in CMS.

When updating or creating suspects/defendants or witnesses/victims the

Unique Identifier in conjunction with name matching as described in

Appendix F will be used to determine whether the entity exists in CMS or

not.




194

Appendix A Relationship to Manual of Guidance

A.1 Pre-charge

A.1.1 Introduction

The documents used to define the interface between the police and CPS, of

which this is one, are concerned with the transmission of electronic pre-

charge material between the police IT systems and the CMS database.

The Manual of Guidance for the Preparation, Processing and Submission of

Files (MOG) is concerned with the proper submission of paper files by the

police to CPS. This documentation does not replace the guidance contained

within MOG for the submission of paper files.

The Physical Case File, including the Paper File remains the master.





This section explains the relationship between the Electronic Case File and

the Paper File component of the Physical File

In this documentation we refer to a number of message types, for electronic

pre-charge decisions:

A Pre-charge Decision Request (CM01);

A Pre-charge Decision Response (CM02);

Charge Information (CM03).

A.1.2 Pre-charge Decision Request (CM01)

The CM01 provides a method of requesting a pre-charge decision

electronically. It is equivalent to the first page of the MG3 or the top half of

the MG3A.

Supplying this information electronically will:

Provide electronic registration of the case;

Create suspects for the case including monitoring information for the

suspects;

Provide a pre-charge information request for the case.




195

A.1.3 Pre-charge Decision Response (CM02)

The CM02 is an electronic representation of a pre-charge decision response.

It is equivalent to the second page of the MG3 or the bottom half of the

MG3A.

The CM02 will provide a response to the police for the pre-charge decision

electronically. This will:

Permit the automated matching up of pre-charge decisions with suspects

and the offences specified by the Duty Prosecutor;

A structured action plan that could be used to plan work;

Structured information relating to the Duty Prosecutor that made the

decision;

Information about the decision itself, e.g. the point of investigation that

the decision was made and how the decision was made

Permit reconciliation of police proposed charges with duty prosecutor

decisions and advised charges (if relevant).

A.1.4 Charge Information (CM03)

The CM03 contains a list of charges put to the suspect. This is similar to the

MG4, the Manual of Guidance Charge Sheet.

It is intended that the CM03 will provide:

Offence information structured to populate the Compass CMS database

and associate the offence with a defendant;

Next hearing information for the case, which will be created in CMS and

associated with the offences passed in for the suspect;

Defence solicitor information for the suspect that may be created for the

case.

Upon receipt of the CM03 for a suspect there is sufficient information for

prosecution proceedings to begin.

A.2 Post Charge

A.2.1 Introduction

The documents used to define the interface between the Police and CPS, of

which this is one, are concerned with the transmission of electronic case

material from Police IT systems to the CMS database.




196

The Manual of Guidance for the Preparation, Processing and Submission of

Files (MOG) is concerned with the proper submission of Paper files by the

police to CPS. This documentation does not replace the guidance contained

within MOG for the submission of Paper Files.

The Physical Case File, including the Paper File remains the master.





This section explains the relationship between the Electronic Case File and

the Paper File component of the Physical File

In this documentation we refer to 2 file types, for Electronic Case Files;

The Initial Case File.

The Full File.

A.2.2 File Types.

There are a number of Paper files, described within MOG.

MOG describes the circumstances in which each file type should be

submitted to CPS. The transmission of digital case material to CMS is in

addition to, and not in substitution for the Physical Case File, including the

Paper File which remains the master.

The Expedited File may be supplied according to the type of first hearing it

is anticipated will take place. There is no difference to proceedings

commenced by way of charge or summons, or postal requisition, unless the

Magistrates‟ Courts Act Procedure has been applied to a summons case,

when in the ordinary course of events the CPS may not expect to be

involved.

Early First Hearing (EFH);

Early Administrative hearing (EAH);

Initial Custody Remand (ICR). This file type may be produced as either

an EFH or EAH.

The form a Paper File takes, when submitted as an Expedited File, or a Full

File is defined within the MOG.

Nothing in the use of the Interface will affect the production of the Paper

File, MOG should continue to be followed for guidance as to the File to be

submitted to CPS and when it should be submitted to CPS.




197

The Electronic File is not concerned with the transmission to the CMS

database of digital copies of paper files except for the MG11 Witness

Statement, MG15 ROTI, MG5, MG5 SP, and the MG6, MG6(c).

The Electronic File is concerned with the transmission to the CMS database

of information that is contained within MOG Forms.

For example, MG1, and MG4 contain details as to defendants and the

offences, with related information as to Victims and others associated with

the case, such as the officer in the case.

The electronic file will not produce copies of those forms, but will receive

the data that is used to create the forms to populate the CMS Database.

A.2.3 Expedited File.

Upon the completion and sending to the CPS of an expedited Paper file for

any of the first hearings mentioned above an electronic file will also be sent

to CMS to register the case with the information contained within the paper

file.

If any of the core information contained within the electronic file is missing

or incomplete this may affect the ability of CMS to register the case. If the

case can be registered then the system may generate tasks for users to

retrieve the core information from the police.

In some instances this may be unavoidable, for example in a custody case

with a short time period between charge and first hearing. However in the

majority of cases the information required to register a case on CMS should

be available to the police and completed on the Police System before

sending to CMS.

It is anticipated that this information will be sent only once to CMS. If it

becomes necessary to amend any of the information previously supplied this

will need to be done by a manual paper process.

Whatever the Paper File created for the first hearing, be it Early First, Early

Administrative or an Initial Custody Remand the information sent to the

CMS database as an electronic file remains essentially the same. Thus we

refer to it as the Initial Case File.

A.2.4 Full File

MOG defines the circumstances in which a full file will be required for

submission to CPS.

In addition to the circumstances specified in the MOG a Full File may be

requested by the CPS for the purposes of drafting or specifying the charges

in those cases in which CPS will have from April 2004 statutory

responsibility for charging.




198

It is intended that the electronic file submitted at the full file stage will

contain:

The Witnesses details as structured data to populate the CMS database.

The Witness statement associated with the witness. This will be

available to view on CMS. It will be baselined, edited or redacted

versions may be produced for presentation at Court.

The exhibit details as structured data to populate the CMS database.

The ROTI associated with a defendant in the case. This will be available

to view on CMS. It will be baselined, edited or redacted versions may be

produced for presentation at Court.

A Full File Flag. This will create the Full File review task on CMS.

After receipt of the full file further information may be sent to CMS:

o New Statements for existing witnesses, associated with the

witness as before.

o New Witness details.

o Statements associated with new witnesses as before.

o New Exhibit details.

o New ROTIS, associated with defendants as before.

As the Full Paper File grows, so should the electronic file on Compass

CMS.




199

Appendix B MG3 Forms

This section contains the MG3 and MG3a that were in use at the time of

writing the initial document.

B.1 MG3 Page 1 Completed by the Police

Figure 60 : The MG3 page 1.




200

B.2 MG3 Page 2 Completed by the Duty Prosecutor

Figure 61 : The MG3 page 2.




201

B.3 MG3A

Figure 62 : The MG3A.

Error! Unknown document property name./ Issue Error! Unknown

document property name.



202

Appendix C Charging Workflow

An example charging workflow chart taken from guidance for custody officers.

Detention

authorised by

Custody Officer

Indictable only /

serious

Offence

within scheme

Advise DP

immediately

C/O decision to

chargePasses PI test?

Passes

evidential test?

Investigation

CompleteCHARGE

Is RIC

Application

Required?

Consider interim

test

Bail 34(5) for

further enquiries

NFA

TIC

Caution

Final Warning

Reprimand

Take action as

appropriate from

MG3

Bail 37(7) with/

without conditions

or RIC

Interim

sufficiency or

evidence tests

passed?

Can offence be

investigated to

conclusion during first

period of custody?

Passes PI test?

Prospect of

further

evidence?

DP determines

further evidence

required

NFA

TIC

Caution

Final Warning

Reprimand

CHARGE

Duty Prosecutor

determines NFA

Yes

No

Yes

Yes

No

No

Yes

No

Yes

NoYes

No

No No

Yes Yes

No

Yes

Yes

No

P

O

L

I

C

E

C

P

S

Figure 63 : Charging Workflow.




203

Appendix D Generic Classification Model

The version 1 Police/CMS interface was very inflexible when it came to adapting to new or extended classification schemes such as

the case level monitoring codes. A new generalised approach will be adopted at version 2 of the interface which will allow existing

monitoring schemes to be extended and new ones added without the need to modify the interface definition schema. The definition of

allowed values will need to be managed externally to this interface by data standards in a way similar to the OU codes are currently.

This appendix shows how existing classification schemes from version 1 of the schema and new classification schemes introduced at

version 2 of the schema will be supported.

The generic structure used to support all these classifications is the Classification Structure. This is illustrated in Figure 64.




204

Figure 64 : The generic classification structure.

The classification structure is used for:

Case Level Classification;

Person Level Classification i.e. Witness/Victim Level and Defendant level Classification;

Exhibit Level Classification;

Case Outline Headings

Case Analysis Headings

Offence Particulars Classifications

Document Level Classification;

Pre-charge Decision Level Classifications (General Decisions, Reasons and Adjudications);

Organisation Level Classification, for suspects/defendants who are not people;

Material Level Classification;

File Option Level Classification;

ClassificationType and ClassificationCode are text strings that describe what data is being classified in the structure and can take the

values shown in the first two columns of the tables that follow in sections D.2 onwards. ClassificationValue gives the actual value for

that data item whose data type is shown in the third column of the aforementioned table and can be one of:




205

“Bool” : Here ClassificationValueFlag would be provided in the XML and take the value true or false;

“Enumeration” : Here ClassificationValueText would be provided in the XML and take one of the values shown in the „Notes‟

column of the data tables. Where the entries there are of the form “code = description” it is the codes that would be provided in

the actual physical message; the accompanying descriptions are just for the reader to understand what the codes mean. If the

entries are not in that format then the value exactly as stated will appear in the messages.

“Text” : Here ClassificationValueText would be provided in the XML and be a freetext character string with no prescribed format

up to a maximum length of 500 characters;

“Int” : Here ClassificationValueInteger would be provided in the XML and be an integer.

D.1 Validation

If a message is received at CMS that contains instances of the classification structure then each such instance is validated at 4 levels.

The validation is performed in a prioritised fashion with each test at a lower level only performed if the previous test at the higher

level passes. The 4 tests are shown in priority order in subsections D.1.1 to D.1.4 below.

If a test at any level fails the message will be rejected and an appropriate business response failure message sent back to the police

system. A message will also be subject to various validation checks across its other fields and the classification structure validation

may be performed at any point within the overall sequence; hence even were the structure destined to fail validation the message may

be rejected for other reasons before the structure is validated.

D.1.1 Test 1 : Classification Inappropriate

The section headings in D.2 onwards below bear the same names found in the XML for elements that expand into the

ClassificationStructure. Where each such element occurs in the XML it may take the Classification Type values listed into the

matching section in this Appendix. For example, in the LM06 the node ExhibitClassification should only be populated with values

listed in section D.5., i.e. where a message is expected to classify a data item in a certain way the first test is to verify the

classification structure is being used for that purpose.




206

If this test fails then a BE37 error is returned, as per MG01.1.13. An example of where a BE37 would be returned on an LM06 is if

ExhibitClassification.ClassificationType = CaseMonitoring from D.2 since case level monitoring codes should not be provided at this

place in the LM06.

D.1.2 Test 2 : Person Classification Not Applicable

The various messages convey information on a number of different types of people as shown in the table below where the contents of

the first column are the names of the elements in the XML that contain an instance of the PersonClassification. Not all the

classifications are relevant to all the types of people though and the „Applies To‟ column in the table in section D.3 shows where the

relevant relationships lie.

If CMS processes a message containing person classifications that are not relevant to the type of person they are classifying then

those classifications will simply be ignored and the message otherwise processed normally. However a BW02 warning message will

be returned to the police advising them they have redundantly/erroneously classified a person.

LM01 LM02 LM03 LM04 LM04u DM01 CM01 WM01 WM01u

PersonDefendant

AccusedPerson

ParentGuardian

DefenceSolicitor

OfficerCompleting

OfficerSupervising

OfficerInCase

Person

UpdatedPerson

AlternateContact




207

D.1.3 Test 3 : Unsupported Classification

The combination of values supplied for ClassificationType, ClassificationCode and ClassificationValue must exist in the tables below

in sections D.2 onwards. If not a BE40 error is returned as per MG01.1.16. An example of this is if in an LM06 the

ExhibitClassification was provided as follows:

ClassificationType = Category

ClassificationCode = Type

ClassificationValue = Sensitive Audio

D.1.4 Test 4 : Duplicate Classification

Repeating values of ClassificationType, ClassificatioCode and ClassificationValue must not be supplied as this would make how the

data is being classified ambiguous. The manner in which duplicate entries in the classification structure are tested for is stated in the

„Unique‟ column in the tables below in sections D.2 onwards and operates at two levels, the scope indicated by „Self:‟ or „Parent:‟

and the degree indicated by „Type + Code‟ or „Type + Code + Value‟. If duplicate data is supplied and this test fails a BE38 error is

returned, as per MG01.1.14.

D.1.4.1 Degree

This shows at what level data supplied must be unique. Where the degree is „Type + Code‟ it means that data supplied in the

classification structure must be unique at the combination of ClassificationType and ClassificationCode. Where the degree is „Type +

Code + Value‟ data must be unique at the combination of ClassificationType, ClassificationCode and ClassificationValue.

For example CaseClassification is labelled with a degree of Type + Code so in the LM06 a CaseClassification of {Category, Media,

Audio} could be provided but not {Category, Media, Video} because this gives non unique values of ClassificationType and

ClassificationCode, i.e. the repeating pair of {Category, Media}




208

D.1.4.2 Scope

This shows at what level in the XML the duplicate combinations are checked for.

„Self‟ means that duplicates are checked for directly within a repeating instance of the classification structure, i.e.

CM01.PreChargeDecisionRequest.CaseClassification.

„Parent‟ means that duplicates are checked for across single instances of the classification structure within a parent element that can

be supplied multiple times, e.g. CM01.PreChargeDecisionRequest.CaseOutlineItem.




209

D.2 CaseClassification

The following table shows the Case Classifications.

Classification

Type Classification Code

Classification

Value Type

(Boolean/Text)

Unique

Version 1 Equivalent Notes

CaseMonitoring ASBOAppliedFor Bool Self:

Type +

Code

New at version 2 Only sent from CPS to Police

ASBOGranted Bool New at version 2 Only sent from CPS to Police

AnimalRightsExtremism Bool New at version 2 Only sent from CPS to Police

AssetRecovery Bool AssetRecovery

ChildAbuse Bool ChildAbuse

CivilActionAgainstCPS Bool New at version 2 Only sent from CPS to Police

CrimeAgainstAnOlderPerson Bool New at version 2

DrugInterventionProgramme Bool CriminalJusticeInterven

tionProgramme

DisabilityHateCrime Bool New at version 2

DomesticViolence Bool DomesticViolence

DVSpecialistCourt Bool New at version 2 Only sent from CPS to Police




210

EarlyGuiltyPleaCrownCourt Bool New at version 2 Only sent from CPS to Police

Fatality Bool Fatality

ForcedMarriage Bool New at version 2

Homophobic Bool Homophobic

HonourCrime Bool New at version 2

IdentifiedVictim Bool New at version 2

MediaInterest Bool MediaInterest

PoliceComplaints Bool New at version 2

PTWIReferral Bool New at version 2 Only sent from CPS to Police

PreChargeDecision Bool PreChargeDecision Only sent from CPS to Police

ProhibitedWeapons Bool New at version 2 Only sent from CPS to Police

Rape Bool New at version 2

RacistCrime Bool RacistReligiousIncident

ReligiousCrime Bool RacistReligiousIncident

SubstantialChargeAlteration Bool New at version 2 Only sent from CPS to Police

VirtualCourt Bool New at version 2 Only sent from CPS to Police




211

VulnerableIntimidatedVictim Bool New at version 2

MCA Bool MCA Only sent from Police to CPS

MCANotGuiltyPlea Bool MCANotGuiltyPlea Only sent from Police to CPS

HumanTrafficking Bool New at version 2 Only sent from CPS to Police




212

D.3 Person Classification

The following table shows the Person Classifications.

The contents of the „Applies To‟ column are described above in section D.1.2. Where the qualifier “W, VW” is used it indicates that

the individual must be marked on the message with a TypeOfPerson value of either Witness or Victim/Witness.

Classification

Type

Classification Code Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes Applies To

EqualityDiversity

SelfDefinedEthnicity Enumeration Self:

Type +

Code

SelfDefinedEthnicity

Uses the current 16+1 values defined by

data standards along with the CMS value

of Not Provided:

White - British

White - Irish

White - Any Other White Background

Mixed - White and Black Caribbean

Mixed - White and Black African

Mixed - White and Asian

Mixed - Any Other Mixed Background

Asian - Indian

Asian - Pakistani

Asian - Bangladeshi

Asian - Any Other Asian Background

Black - Caribbean

Black - African

Black - Any Other Black Background

Other - Chinese

Other - Any Other Ethnic Group

Not Provided

Not Stated

PersonDefendant

AccusedPerson

Person

UpdatedPerson

AlternateContact




213

SelfDefinedReligionBelief Enumeration New at version 2 Uses a new enumeration scheme

(possibly to be adopted by data

standards) based on the CMS set of:

Buddhist

Christian

Hindu

Jewish

Muslim

No Religion

Not Provided

Not Stated

Other Religion

Sikh

SelfDefinedDisability Enumeration New at version 2 Uses a new enumeration scheme based

on the CMS set of:

Yes

No

Unknown

SelfDefinedGender Enumeration Gender Uses the current 4 values defined by data

standards:

Unknown

Male

Female

Indeterminate




214

Languages

SelfDefinedPreferredLanguage Enumeration WelshDocuments Uses the ExISS v1 enumeration of:

Welsh

English

PersonDefendant

AccusedPerson

Person

UpdatedPerson

DefenceSolicitor

AlternateContact

TypeOfWitness

Child Bool Child Person W, VW

UpdatedPerson W,

VW Expert Bool Expert

Interpreter Bool Interpreter

Police Bool Police

Professional Bool Professional

Special Bool Special

Prisoner Bool New at version 2

Vulnerable Bool Vulnerable Person

UpdatedPerson Intimidated Bool New at version 2 It is now possible to separate out the

concepts of vulnerable and intimidated.

StatusInformation NumberOfTICs Num NumberOfTICs PersonDefendant




215

OffenderType Enumeration New at version 2 Uses the following enumeration scheme:

BP = Both Persistent Prolific Offender

and Deter Young Offender

PP = Persistent Prolific Offender

DY = Deter Young Offender17

YO = Young Offender

UN = Unspecified

AccusedPerson

TICsOnFile Bool TICsOnFile

PreviousConviction Bool PreviousConviction PersonDefendant

AccusedPerson

Person

UpdatedPerson

PreviousCaution Bool PreviousCaution PersonDefendant

AccusedPerson

PreviousFinalWarning Bool PreviousFinalWarning

PreviousReprimand Bool PreviousReprimand

17 Until CPS agree to adopt the new standards for offender type classifications, values of DY passed to CMS in the ExISS v2 interface will behave the same as

the old PY value and mark a suspect/defendant as a Persistent Young offender in CMS.




216

SeriouslyDangerousOffender Text New at version 2 Contains the reason for why a defender is

a seriously dangerous offender (SDO).

The presence of this value indicates that

a defendant is an SDO. If no reason is

available and the defendant is an SDO

then this field will be populated with „No

reason specified‟.

PrisonerOnLicense Bool New at version 2 Records that a defendant/suspect is a

prisoner out on license from a custodial

sentence.

Note: is included for future proofing but

is currently ignored by CMS.

NoDirectContact Bool NoDirectContact Person

UpdatedPerson

KeyWitness Enumeration New at version 2 Uses the following enumeration scheme:

Yes

No

N/A

Unknown

Person W, VW

UpdatedPerson W,

VW




217

D.4 DocumentClassification

The following table shows the Document Classifications.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

Document DocumentType Enumeration Self:

Type +

Code

TypeOfDocument Uses the following enumeration scheme, largely

based on the v1 set for TypeOfDocument. Bold text

indicates a change from v1:

Incoming to CMS

MG 1 - File Front Sheet MG 2 - Special Measures Assessment

MG 3 - Charging Decision Log and Plan

MG 3A - Further Charging Decision Log and Plan MG 4 - Charges

MG 4A - Conditional Bail Grant/Variation

MG 4B - Request to Vary Conditional Bail MG 4C - Surety/Security

MG 4D - Postal Requisitions Attendance Required

MG 4E - Postal Requisitions Attendance Not Required

MG 4(Post) - Written Charges

MG 4F - NFA Template Letter

MG 5 - Summary of Evidence

MG 5(SP) - Directors Guidance Streamlined Process

MG 6 - Case File Information

MG 6A - Record of Pre-Interview Briefing

MG 6B - Police Officer/Staff Disciplinary Record

MG 6C - Unused Material Disclosure Schedule

MG 6D - Sensitive Material Schedule MG 6E - Disclosure Officers Report

MG 7 - Remand Application Form MG 8 - Breach of Bail Conditions

MG 9 - Witness List

MG 10 - Witness Non-Availability MG 11 - Witness Statement

MG 11(R) - Witness Details




218

MG 12 - Exhibit List

MG 13 - Application For Order on Conviction MG 14 - Conditional Caution

MG 15 - Record of Interview (SDN)

MG 15 - Record of Interview (ROTI)

MG 15 - Record of Interview (ROVI)

MG 15 - Contemporaneous Notes of Interview

MG 16 - Defendants Bad Character Information

MG 16 - Defendants Dangerous Offender Information

MG 16 - Defendants Bad Character/Dangerous Offender Information

MG 17 - Proceeds of Crime Act (POCA) Review MG 18 - Offences Taken Into Consideration

MG 19 - Compensation Claim Form MG 20 - Further Evidence Report

MG 21 - Submission of Work for Scientific Examination

MG 21A - Submission of Additional Work for Scientific Examination

MGDD - Drink Drive Evidential Procedure

PE 1 - Pre-charge Evidential : witness statement

PE 2 - Pre-charge Evidential : ROTI/SDN

PE 3 - Pre-charge Evidential : Bundle

PE 4 - Pre-charge Evidential : other

DREP - Defence Representations at pre charge

PCN 1 - Defendant/Suspect Previous Convictions (Prosecution Print)

PCN 2 - Defendant/Suspect Previous Convictions (Court Print)

PCN 3 - Witness Previous convictions

Other

If the police categorise documents in any way other

than stated in the list above the LM07 message will

be rejected.

Incoming to Police

CCCP17 - S41 Schedule CCCP23C - Covering Letter (Police)

CMS01 - Indictment

CMS01a - Indictment (CCC) CMS43 - Further Charges

CMS53 - S51 Schedule

CMS55 - Schedule of Charges CMS56 - Victim - Insufficient Evidence

CMS57 - Victim - Not in Public Interest

CMS58 - Witness Summons - Memo to Police CPIA03 - Def Statement to Police (pre Apr05)




219

CPIA06 - Copy MG6C to Police (pre Apr05)

CPIA3 - Def Statement to Police CPIA6 - Copy MG6c to Police

CPR3 - Application for a Witness Summons

DGCC - Conditional Caution Authority DGYCC - Youth Conditional Caution Authority

DN01 - Disc Notice (Police)

DN02 - Dropped/LOF (Police) DP01 - Proposed Discontinuance

MG17 - Proceeds of Crime Act (POCA) Review MG3 - Charging Decision Log and Plan

MG3S - MG3 (with Schedule of Charges)

MG3A - Further Charging Decision Log and Plan MG3AS - Further Charging Decision Log and Plan (with Schedule of Charges)

NFE01 - Notice Further Evidence

NFE03 - Letter (Police) POL1 - Police Memo

POL2 - Pre-charge Police Memo

POL3 - Quick Police Memo REV1 - Review Document

S9 - S9 Notice

SC01 - Schedule of Charges WEF04 - LWAC

WEF04(Cont) - LWAC Continuation

Other

If CMS categorises documents in any way other than

stated in the list above the LM07 message will be

rejected.




220

D.5 ExhibitClassification

The following table shows the Exhibit Classifications.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1 Equivalent Notes

Category Media Enumeration Self:

Type +

Code

TypeOfExhibit Uses the following enumeration

scheme:

audio

video

sensitiveVideo




221

D.6 CaseOutlineHeading

The following table shows the CaseOutlineHeading Classifications.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

CaseOutline Heading Enumeration Parent:

Type +

Code +

Value

New at version 2 Uses the following enumeration scheme:

KEVD = Summary of Key Evidence

DINT = Defendant Interview

NEVD = Non Key Evidence

VEVD = Visually Recorded Evidence

INJS = Injuries

FFDE = Fingerprint/Forensic/Drugs Evidence

ISS = Issues

OUTW = Outstanding Work

SIAV = Sensitive Information

DIP = DIP Testing

ACOC = Application for Court Orders and Compensation

AREC = Asset Recovery




222

D.7 ParticularsClassification

The following table shows the Particulars Classifications.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

Substitution Location Enumeration Self:

Type +

Code +

Value

New at version 2 Uses the following enumeration

scheme:

Township

Flight Number and Airport Details

Name of Ship

Address

Location

Train

Land




223

D.8 CaseAnalysisHeading

The following table shows the CaseAnalysisHeading Classifications.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

CaseAnalysis Heading Enumeration Parent:

Type +

Code +

Value


SUEV = Evidential Criteria

PINT = Public Interest

MOT = Mode of Trial

EHCR = European Court of Human Rights

BSUM = Brief Summary

EVIS = Case Analysis/Evidential Issues

CHPL = Charge / Plea Issues

WIVI = Witness / Victim Issues

NTCP = Instructions to Court Prosecutor




224

D.9 GeneralDecison

The following table shows the GeneralDecision classifications used in a pre-charge response.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

GeneralDecision Response Enumeration Self:

Type +

Code


A = Charge + Request Evidential File

B = Charge + Request Expedited File

B2 = CC Non-compliance - Charge + Request Expedited File

C = Simple Caution

D = Conditional Caution

D2 = CC Non-compliance - No Prosecution

D5 = CC Non-Compliance - Continue - Variance

E = Reprimand

F = Final Warning

G = TIC

H = Request Further Evidence to Complete Evidential Report

I = Request Further Evidence to Complete Expedited Report

J = Early Advice: Further Action Necessary

K = No Prosecution - Evidential

L = No Prosecution - Public Interest

M = Other

Z = Admin Finalised




225

D.10 ReasonCode

The following table shows the ReasonCode classifications used in a pre-charge response.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

ReasonCode Response Enumeration Self:

Type +

Code


E1 = Inadmissible evidence - Breach of PACE

E2 = Inadmissible evidence - other than Breach of PACE

E3 = Unreliable confession

E4 = Conflict of evidence

E5 = Essential medical evidence missing

E6 = Essential forensic evidence missing

E7 = Essential legal element missing

E8 = Unreliable witness or witnesses

E9 = Key victim does not support case

E10 = Key witness does not support case

E11 = Unreliable/lack of identification

P12 = Effect on victim‟s physical or mental health

P13 = Suspect/Defendant elderly or in significant ill health

P14 = Loss or harm minor and single incident

P15 = Loss or harm put right

P16 = Long delay between offence/charge or trial

P17 = Very small or nominal penalty

P18 = Other indictment / sentence

P19 = Informer or other public interest immunity issues

P20 = Caution more suitable

P21 = Youth of offender

P22 = Conditional caution more suitable

P36 = Inappropriate to compel victim

P37 = Inappropriate to compel witness




226

P38 = Adequate compliance

P39 = Change in circumstances




227

D.11 AdjudicationDecision

The following table shows the AdjudicationDecision classifications used in a pre-charge response.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

AdjudicationDecis

ion

Response Enumeration

Self:

Type +

Code

New at version 2

Uses a new enumeration scheme (possibly to be

adopted by data standards) based on the following:

Accept

Accept with Variation

Replace

Reject

Caution

Taken into Consideration

Further Enquiries

No Prosecution - Evidential

No Prosecution - Public Interest

CC Non Compliance - No Prosecution




228

D.12 OrganisationClassification

The following table shows the Organisation Classifications.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

None Identified.




229

D.13 Material Classification

The following table shows the Material Classifications.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes

Material MaterialType Enumeration N/A New at version

2

Uses the following enumeration scheme:

STMT = Statement

ROTI = Interview Record

FEXE = Forensic/Expert Evidence

PNB = Pocket Note Book/Incident Report Book

PINL = Police Incident Log

VIDP = Video/Photographs

PCON = Previous Convictions/Disposals

DREP = Defence Representations at pre charge

OTHR = Other




230

D.14 FileOptionClassification

The following table shows the File Option Classifications.

Classification

Type

Classification

Code

Classification

Value Type

(Boolean/Text)

Unique Version 1

Equivalent

Notes




231

FileBuild Information Enumeration Parent:

Type +

Code +

Value

New at version

2

Uses the following enumeration scheme:

KWD = Key Witness Details

KWS = All Key Witness Statements

NKWD = Non-Key Witness Details

NKWS = Additional (Non-Key) Witness Statements from:

WA = Witness Availability

VPS = Victim Personal Statement

SM = Special Measures Material

PCW = Previous Convictions for all Prosecution Witnesses

ROTI = ROTI

KEX = Key Exhibits

IDEV = Identification Evidence

CCTV = CCTV Material

VREV = Visually Recorded Evidence

IDAS = Initial Drugs Assessment

FEV = Forensic Evidence

MEV = Medical Evidence

USM = Unused/Sensitive Material

BCDO = Bad Character/Dangerous Offender Info

OCON = Orders on Conviction

POCA = POCA Review

COMP = Compensation Details

OTH = Other (specify)

Error! Unknown document property name./ Issue Error! Unknown

document property name.



© 2014

232

Appendix E Police Consultation Matching

Within the COMPASS CMS system each pre-charge consultation broadly

comprises 2 types of data:

A single structured narrative from the Duty Prosecutor outlining the

evaluation of the circumstances and evidential material. The narrative is

broken down into different categories assessing factors like Public

Interest, ECHR etc and is typically referred to as the “case analysis”.

A set of decisions, one per suspect on the case, falling into the classes of

“prosecute”, “no further action” or “request for further information”.

Collectively these form a completed consultation and both types of data (the

case analysis and set of suspect decisions) are included on the CM02

message. Within CMS each consultation is assigned a unique identifier

which is included on the CM02 message.

The business process has agreed that suspects without an Arrest Summons

Number (ASN) recorded in CMS will not be sent on a CM02 as there is a

risk that such suspects would not be know to the Police IT systems. Such

suspects may acquire an ASN in CMS later on18 and at that point there

should be a limited form of catch-up whereby the last consultation the

suspect was given a decision at is then sent out on the CM0219 and this

would happen irrespective of where the case is in its lifecycle

It is possible that on 2-handed case one suspect (A) on CMS may have an

ASN recorded and the other (B) may not. Both suspects may be the subject

of a single consultation but only suspect A would be included on the ensuing

CM02. At a later date when suspect B has his ASN set he too would be sent

out on a second CM02.

As part of the CM02 CMS would include the Consultation Id. When the

police systems process and store the data in a CM02 they can check if they

have already seen the Consultation Id before. If not, it represents a new

consultation which can be created in the police system and associated with

each suspect decision on the CM02 (as would be the case for the 1st CM02

in this example). If so (as would be the case for the 2nd

CM02 in this

example) they know it doesn‟t represent a new case analysis, rather it‟s the

delayed notification of a suspect decision for an existing consultation and

they can link that decision to that existing consultation.

18 Note: The ASN cannot be edited or entered in CMS, it can only be provided by the police

in a TWIF message.

19 More exactly, this is the last completed consultation where the suspect was given a

decision other than „not given for this suspect‟. If the suspect has only ever been given „not

given for this suspect‟ decisions then no CM02 is sent at all.




233

The TWIF business process is not in a position to demand to what use the

CM02 is put in each police system - this is at the discretion of each police

force although the assumption would be the case analysis in each CM02

would be stored along with the decision given for each suspect at that

consultation. In the scenario above even though there would be two CM02

messages, only one consultation would have been done on CMS, it‟s just

that the decision for each suspect at that single consultation has been sent on

separate messages.




234

Appendix F Party Matching

At version 1 of the interface, the only permissible way to identify a

defendant/suspect uniquely was their Unique ID. However, since the version

2 interface will need to work alongside separate Pre-Charge sources, a name

and date of birth matching fall back will be required.

Messages received via this interface will first attempt to match to a

defendant suspect on the case with the same unique identifier. If this fails

they will attempt the name matching algorithm below. If a match is made,

the Defendant/Victim on CMS will be updated to include the unique

identifier contained in the message. If name matching fails to find a unique

match (in both directions) the received detail will be used to create a new

suspect/defendant.

The three attributes that are required for matching are Surname, Forename

and date of birth. A defendant match must always match on Surname and

one of Forename or date of birth. However mismatches in any of these fields

are not allowed, but a null value does not count as a mismatch.

The following table shows what field matching is required to achieve

defendant matching. The following symbols are used:

≠ - For a mismatch;

≡ - For a match;

? - Where one or both in the pair are null

Surname Forename Date of

Birth

Defendant

Matched

matching

1 - Surname must match ≠ ? ≠ ≡ ? ≠ ≡ ? ≠

2 - Mismatch ≡ ≠ ? ≡ ≠

3 - Mismatch ≡ ? ≡ ≠ ≠

4 - Single match ≡ ? ? ≠

5 - Double Match ≡ ≡ ? ≡

6 - Double Match ≡ ? ≡ ≡

7 - Triple Match ≡ ≡ ≡ ≡




235

For surname and date of birth, a match constitutes an exact match.

For Forename(s) a match constitutes one Forename string being a left

aligned substring of the other. The following examples illustrate this:

Candidate 1

Forename(s)

Candidate 2

Forename(s) Match

John Nelson John Nelson Yes

John John Nelson Yes

John Nelson John Yes

John N John Nelson Yes

John Neptune John Nelson No

John Nelson No

Nelson John Nelson No

When matching on names, if an incoming defendant/suspect matches to

more than one defendant/suspect in CMS, then this does not constitute a

match. However, this is deemed a match when matching on unique

identifier.

If more than one incoming defendant/suspect in the same message match to

the same defendant/suspect on CMS then this does not constitute a match.

These same matching rules are also used in support of the LM04 message

whereby CMS determines if an incoming victim/witness on the case already

exists on CMS and if so its details are updated rather than a new

victim/witness created. It is worth noting that the police could also adopt

this strategy when receiving WM01u messages from CMS and if so they are

advised to use the same name matching algorithm described here.




236

Appendix G Offence Matching

Give Matching algorithm and justification for it

TBD (if necessary)




237

Appendix H Message Ordering

H.1 Introduction

Under the TWIF CMS may receive any of 12 different types of message and

police 7 different types, namely:

Received by CMS Received by Police

CM01, CM03

FM03

LM01, LM02, LM03, LM04, LM04u,

LM05, LM06, LM07, LM08

CM02

DM01

FM01, FM02

LM07

WM01, WM01u

As case data is modified in either CMS or Police end point systems this

causes messages to be generated which are eventually delivered to and

processed by the other end point systems. All messages are associated with a

case but each one provides different information about the case and some

messages depend on other messages having already been received in order

for them to be successfully processed. However the architecture of the CJSE

Exchange and the message transmission/receipt modules at the end point

systems means that it is not possible to guarantee messages will necessarily

be received and processed by one end point system in the order they were

generated and sent by another one.

If messages are processed out of order two common classes of problem may

occur:

1. Messages that depend on other data existing will fail. For example if a

witness and his statement are created by the police and sent on an LM04

and LM05 message then the LM05 will fail processing at CMS unless

the LM04 message has already been processed to create the witness that

the LM05 will attempt to attach the statement to.

2. Messages that update data may leave stale results. For example if the

police update a witness twice in a matter of hours and send two LM04u

messages a delay in the CJSE Exchange could mean both messages

arrive at CMS at the same time. The first message sent out from the

police could be processed last by CMS leaving CMS with an out-of-date

picture of the witness because the up-to-date picture would have been on

the second message sent out from the police which could have been

processed first at CMS and then had its data overwritten by the other

message.

The TWIF Working Group debated various strategies of varying complexity

to mitigate these problems and ensure messages were processed in the

correct order. The most ambitious of these was to maintain a message




238

sequence number per case where each message for that case was tagged with

the number of the message last produced for it. When the messages were

received by the end point systems they could be held back, sequenced and

processed in the original production order even if they arrived out of order.

This scheme was discounted though because the message sequencing issue

is fundamentally more of a problem for CMS than the police systems and it

was felt it would have introduced unnecessary complexity into the police

systems to support. Instead, the Working Group agreed a mitigation

approach based on 2 principles:

A simple timed precedence scheme similar to that used in ExISS version

1. This would manage the problem described in 1. above. See H.2 and

H.3 below.

A limited form of data numbering to manage the problem described in 2.

above. See H.4 below.

H.2 Timing Precedence in CMS

Messages are assigned to one of the following 5 categories:

Precedence Description Messages

1 Messages registering new cases LM01, CM01

2 Messages adding entities to cases (except

statements)

LM02, LM04, LM06,

LM07, LM08, CM03

3 Messages adding witness statements LM05

4 Messages updating witnesses or defendants LM04u, LM03

5 Split/Merge confirmation messages FM03

If a series of messages are received for the same URN at the same time then

messages having a lower precedence number will be processed by CMS

ahead of those with a higher precedence number. If different messages types

have the same precedence number then CMS will not be deterministic over

which ones are processed first.

This order of processing holds regardless of the order the messages were

produced by the sending system or the order in which they arrived at CMS.

Further, if a set of messages produced by a police system arrive at CMS

neither at the same time not in the order they were originally produced and

one of those messages fails because data it depends on exists in another

messages yet to be seen by CMS then that failed message is scheduled for

another processing attempt at a later time, by which stage the missing

dependent message may have arrived at CMS and been processed. The re-

scheduling delay and the number of re-attempt cycles are both configurable

in CMS. Only at the end of the last cycle would the police system then be

informed of the message failure.

In particular this includes the scenario where CMS splits a case (say URN A

into A/1 and A/2) but the police start to send messages directly from the

split child cases without CMS having being notified of the completion of




239

their split via an FM03. These messages would be retained and re-attempted

as part of the retry cycle to give the FM03 a chance to arrive. Only at the

end of the retry cycle if the FM03 is still absent would the messages then be

rejected with a BE49 error.

When a case is first created in police systems the approach is sometimes

used that case data is fleshed out and then relevant messages manually

triggered to be sent to CMS en-masse. To reduce the extent here to which

message dependency delays are incurred because the CJSE may deliver

them in a random order to CMS it is recommended as a best practice that

police force systems first send an LM01 or CM01 and then only send on

subsequent messages once CMS has acknowledged receipt of the

LM01/CM01. The Working Group agreed that, whilst beneficial in theory, it

is less important to recommend the same best practice for the more specific

LM04/LM05 dependency when sending witnesses and their statements.

H.3 Timing Precedence in Police Systems

The police systems receive fewer messages than CMS and there are fewer

dependencies amongst them. Police systems are free to implement any

scheme they wish to mitigate the effects of receiving and potentially

processing messages out of order, but if a similar timed precedence scheme

was used that CMS deploys, the TWIF Working group would recommend

using the following precedence categories:

Precedence Description Messages

1 Messages adding entities to cases CM02, FM01, FM02,

LM07, WM01

2 Messages updating witnesses or defendants DM01, WM01u

Police systems should also consider implementing a configurable number of

retry attempts to process a WM01u in case a related dependent WM01

message is delayed before failing the message and notifying CMS.

H.4 Update Ordering

Even with the implementation of timing precedence described above there

are three classes of problem that can occur when processing witness update

messages. These are described below and all ultimately solved by both sides

maintaining a witness version number which is held within each of their

systems and transmitted as an attribute on the LM04u and WM01u

messages.

H.4.1 Scenario 1 : The Simple Update

One side, say the police, may make an update to a witness and follow this

with a further update later on. Each update will produce an LM04u message

sent to CMS. If the updates are some time apart, several hours or more, it is

likely that the first LM04u message will arrive at CMS and be processed




240

before the second, thus ensuring the second message is processed last on

CMS which will keep CMS‟s portrait of the witness in-line with the portrait

the police have.

If the updates are closer together though, the combination of the Exchange

not guaranteeing messages to be delivered in the order they were received

and the ability of CMS to process multiple messages simultaneously means

the 1st message may end up being processed on CMS after the 2

nd message.

This will cause CMS‟s portrait of the witness to be de-synchronised with

that of the police, since the most up-to-date details on the 2nd

message have

been overwritten with the outdated details on the 1st message.

The examples which follow are simply illustrated by assuming that both

sides are updating the name of a witness to different values at different

times. Of course, in practice many attributes may be updated via any single

message but the concepts are the same.

Synchronised De-synchronised

Police CPS

John John

Dave

LM04u

Frank

LM04u

Dave

Frank

Police CPS

John John

Dave

Frank

Frank

Dave

LM04u

Thus, the problem is that if CMS has a backlog of multiple witness update

messages to process which order should it do them in to ensure it ends up

with the same portrait of the witness currently held on the police system?

To protect against this problem the solution is for each side to tag its

witnesses with a version number. When one side first creates a witness it

will be tagged with version number 1 and an LM04 or WM01 sent to the

other side saying create this witness at version 1. When a side updates a

witness that causes an update message to be sent20 it will increment its

version number and send an update message to the other side saying to

update the witness with the details on the message and set the version

number to the incremented value, also carried on the message. This would

have the following effect on the de-synchronised example above.

20 Note: either side may maintain local witness attributes that the interface does not require

to be sent to one another. If only these are updated then there is no need to increment the

version number or send out an update message.




241

Re-synchronised

Police CPS

John 1 John 1

Dave 2

Frank 3

LM04 (1)

Frank 3

LM04u (3)

LM04u (2)

X

Here, it doesn‟t matter what order CPS process the LM04u messages in. The

key rule is that an update message is ignored unless it attempts to

raise the version number higher than it already is. CPS processes

the 2nd

LM04u from the police immediately updating the witness John into

Frank and assigning it version 3. When it later processes the 1st LM04u from

the police it knows to ignore it because it is saying update the witness with

these details (Dave) and assign it the version number 2, but the CPS witness

has already moved onto version 3. A normal business success response

would be sent back for each LM04u in this scenario. At the end of the

message processing both sides are synchronised with the same witness

details as each other, both at version 3.

If CPS processes the police messages in the order they were produced this

scheme still works since on the CPS side John would be updated to Dave at

version 2 and then to Frank at version 3, leaving both sides synchronised.

The process is symmetric and either side can update the witness,

incrementing the version and telling the other side to do likewise.

H.4.2 Scenario 2 : The Crossed Update

In this situation both sides have their witness portraits synchronized, but one

side updates the witness on their system and sends an update message to the

other side at the same time that other side is doing exactly the same thing,

resulting in the following:




242

De-synchronised

cross update

Police CPS

John 1 John 1

Dave 2

LM04 (1)

Frank 2

WM01u (2)

LM04u (2)

If each side accepted the other‟s update message then both sides would end

up swapping portraits with each other - the police witness being called Frank

and the CPS one called Dave. They would remain de-synchronised. The

same witness version numbering scheme described in scenario 1 allows us

to detect a crossed update because each side will receive a message telling it

to update a witness to a version number it‟s already at. When this happens

the business process has agreed that the police will accept the WM01u

update and CPS will ignore the LM04u update, resulting in this:

Synchronised cross update

Police CPS

John 1 John 1

Dave 2

LM04 (1)

Frank 2

WM01u (2)

LM04u (2)

Frank 2

X

Both sides are synchronized with Frank at version 2. Again, external

dialogue would be necessary to check whether Frank was correct or whether

Dave is the right name after all. Either side could initiate this dialogue

knowing they had received a cross-over message. If Frank is correct no

further action is needed on either side; if not then the police would update

Frank at v2 to Dave at v3, as per normal, and an LM04u (3) sent to

synchronise CPS. This approach is favoured because the data is

synchronised whilst the need for any corrective updates is being assessed




243

and if there is a need to amend data then one side does it naturally by

changing their witness from its current value to a different value.

Whilst messages are not being delayed by the end-to-end infrastructure, a

crossed update would be rare but rarer still is a multi crossed update where

one side makes multiple edits that cross over with the other side. Take the

following example:

Multiple cross updates

Police CPS

John 1 John 1

Dave 2

LM04 (1)

Frank 2

WM01u (2)

LM04u (2)

Jim 3

LM04u (3)

Frank 4

LM04u (4)

Joe 3

WM01u (3)

From the initial synchronised position of John 1 on both sides, the police

make 3 updates and the CPS make 2 before either side receives the other‟s

update messages. On the police side, by the rules outlined in Scenario 1,

both WM01u messages will be ignored because they provide version

numbers lower than that already on the police side (i.e. 2 and 3 versus 4).

The police will not see this as a crossed update and will take no further

action with the CPS messages. On the CPS side the LM04u(2) is certain to

be ignored as its version is lower than currently exists there (the 3 for Joe).

If the LM04u(4) is processed first it will be seen as a normal Scenario 1

situation and will turn Joe 3 into Frank 4, leaving both sides synchronised

and causing the LM04u(3) to be ignored. If the LM04u(3) is processed first

then a crossed update would be detected as CPS is already at version 3 with

Joe. The LM04u(3) will be ignored, but again the LM04u(4) is still going to

be successfully processed anyway, restoring the synchronisation of both

sides at Frank 4.

So where there is cross over of a different number of messages from each

side, by the simple processing rules above synchronisation would always

end up being restored via the data held in the latest such message amongst

those crossing over, although the crossover itself may not go detected.




244

Where there is a crossover of the same number of messages the simple

processing rule from Scenario 1 mean all the lower numbered messages will

be ignored and the highest numbered message will produce the same

crossover situation as outlined in the one message crossover situation at the

start of this scenario 2 section.

H.4.3 Scenario 3 : The Rejected/Accepted Update

Section 5.1.7 describes an approach to managing witness updates in which

there is room for one side to not unconditionally accept the updates sent by

the other side - particularly the case on CMS where contact details of

civilian witnesses on WCU allocated cases are changing. The idea of the

witness version number described above still fits in with this approach as

shown below.

Pending Updates

Police CPS

John … 1 All attributes accepted

Dave … 2

LM04 (1)

LM04u (2) Unconditional

updates accepted

Conditional

updates pending2

Mike … 3 LM04u (3) Unconditional

updates acceptedConditional

updates pending

and overwritten

3

WM01u (4)

CMS unconditional

updates made

CMS conditional

updates pending 4

All conditional updates accepted. Witnesses fully synchronised and remain at v3.

One or more pending

conditional updates rejected44Unconditional

updates accepted

Conditional

updates pending

WM01u (4)4Unconditional

updates accepted

In this sequence the police create a witness and send it to CPS via an LM04.

The police then change various attributes on the witness and send an

LM04u(2) to CPS. Any changes to non contact details are applied on CMS

and contact detail changes are held back as pending updates until they are

confirmed. It doesn‟t matter if all the changes are conditional, if they are all

unconditional or if they are a mixture of both. CMS still updates its witness

to v2 on receipt of the LM04u. The police may continue in this manner,

updating at will and driving their and the CMS version number ever higher.

At some point one of three things can happen on the CPS side:




245

1. A user adjudicates on the pending changes with them all being accepted.

Both sides then become fully synchronised, the version numbers stay as

they are and no further messages are sent as this happens.

2. A user adjudicates on all the pending changes with one or more of them

being rejected and their equivalent existing CMS values taking

precedence. A WM01u is sent back to the Police containing details of

the witness as it now stands on CMS and some of the witness attributes

will be different on CMS to the police system. The version number is

incremented. The police are now in the same symmetric position CPS

was and have these same 3 choices available.

3. A user edits aspects of the witness but leaves the conditional updates as

pending. A WM01u is sent back to the police and contains details of the

changed attributes and the conditional pending attributes that have yet to

be confirmed. From the police‟s perspective there is no change to the

pending attributes - in particular any variation between them and the

CMS values are not exposed in the WM01u until they are actually

rejected or accepted. The version number is also incremented here.

H.4.4 Conclusion

Whilst appearing more complex, scenario 3 is still ultimately just the

exchange of witness update messages where the version is maintained on

both sides. Within scenario 3 multiple messages may be sent from one side

to the other and would be managed as described in Scenario 1 and message

updates may cross and would be managed just as described in scenario 2.

The version numbering scheme described above is relatively simple to

implement and covers the majority of likely message exchange scenarios

allowing both sides to remain synchronised and there is no immediate cost

benefit in implementing more complex solutions.

The approach outlined above would also apply to the defendant update

messages, the DM01 and LM03, even though scenario 3 wouldn‟t arise

since the notion of conditional pending updates does not form part of the

business process there.

H.4.5 Ignoring Updates

Since the TWIF interface went live, some force systems have chosen to not

process WM01u witness update messages from CMS, primarily because

they model a witness as a „golden nominal‟ meaning its exists once in a

force database even if it‟s referenced on several separate cases. CMS uses

case local witnesses where if the same person in the real world is involved in

separate cases they are represented on those cases as independent separate

database records that can be updated in different ways to one another if

necessary.

At the time of v1.0 issue, this BPD does not define an agreed business

process to manage bi-directional updates in this situation that keeps all the




246

witness data synchronised between the golden nominal and the various case

local representations of the witness.

An approach to this lack of defined business process is for the police to

ignore WM01u messages to keep absolute control of the data on their golden

nominal, but this does mean that the witness portrait will become

desynchronised between police systems and CMS if witness updates are also

made in CMS, contrary to the principles outlined in section 5.1.7.2.

If a force operates in this manner (in particular where the golden nominal is

only referenced on a single case) then when a WM01u is received, although

its data is ignored and not applied to the golden nominal, the version number

on the WM01u must still be applied albeit still adhering to the principles

described in H.4.1 to H.4.3, as illustrated below:

Ignored update

Police CPS

John 1 John 1

Dave 2

LM04 (1)

Dave 2LM04u (2)

Bill 4

LM04u (4)

Pete 3

WM01u (3)Dave 3

Bill 4

The important thing here is that when the WM01u is received even though

its business data update is ignored keeping the police‟s view of the name

unchanged the version moves on to 3 in line with the value held on CMS.

This way, further updates made in the police system sent on an LM04u can

be updated in CMS because they will raise the version number there. If the

version wasn‟t raised on the police system on receipt of the WM01u the

update to Bill would send an LM04u with version 3 and this would be

ignored on CMS.

This exact problem was observed on the live system in Spring 2012. If the

version is updated as described above then it suits golden nominal forces

where most WCOs work directly on the police systems which effectively

become the master source of witness data. Even is occasional updates are

made in CMS/WMS the version number updates on the police side allow

further police messages to be applied in CMS. The one problem here of

course is that those very updates done on CMS become lost after a

subsequent police update. For example:




247

1. Police create witness John with phone number 123 and send LM04 to

CMS where John 123 is created at version 1.

2. Police update 123 to 456 and send an LM04u at v2 where it is fully

applied to CMS.

3. CPS update religion to Christian and send WM01u at v3.

4. Police don‟t apply business data in WM01u but update version to 3.

They now hold name=John, phone=123, religion=null.

5. Police update gender to Male and send in an LM04u at v4.

6. CPS applied the LM04u and in the process has the phone number

reverted to 123 and the religion reverted to blank.

These lost updates are likely to eventually cause one side an issue. The

extent to which this is likely to happen needs to be discussed and agreed in

the IBA on a per force/area basis as edits made in CMS and WMS are likely

to be lost and the practice would need for these to be minimised. This is

particularly likely to an issue for areas where WCU staff work

predominantly in WMS and but the area is aligned with a force that uses

golden nominals and doesn‟t apply WM01u messages, yet still wants to

make witness updates. For such golden nominal based forces, without a re-

engineering of how the synchronisation works, the problem can be mitigated

by either:

Core witness data being updated only in force systems. Here inadvertent

edits to data in CMS/WMS will be lost if further police edits made but

these would be infrequent; OR

Core witness data being updated only in CMS/WMS and never in force

systems. Here any updates in force systems will invariably lose all edits

previously made in CMS/WMS.

H.5 Delete Versioning

When one side deletes a victim or witness an LM04u or WM01u is sent to

notify the other side of this. In this situation the side performing the delete

must not alter the version number of that person. This ensures that if the side

being notified:

rejects the deletion (leaving their vic/wit untouched) then when the

deleting side logically undeletes the person both sides have the vic/wit at

the same version number and thus are still synchronised. Implicit here is

the fact that the side doing the deletion rejection must not raise the

version number of their vic/wit. This is logically consistent since nothing

about that person is changing in the act of rejecting the deletion request.

accepts the deletion then at some future point if there is mutual

agreement that the vic/wit has to bilaterally logically undeleted then




248

when both sides have done so they have the same version number and

are thus still synchronised.

The key rule stated in H.4.1 above that “an update message is ignored

unless it attempts to raise the version number higher than it

already is.” thus applies specifically when an LM04u/WM01u is received

operating in Update or Update Rejection mode. It does not apply when

these messages are operating in Delete or Delete Rejection mode since by

design the version number on the message then would be the same as held

against the person and if the rule was in place would cause the message to

be ignored. For Update or Update Rejection modes the version number on

the message should simply be ignored and not play any part in deciding if or

how the message is processed.




249

Appendix I Potential Changes

I.1 Introduction

This appendix documents various observations, issues and wishes that have

been identified and expressed to a greater or lesser extent by the Working

Group participants over the course of refining the TWIF specification, end-

to-end testing and post go-live operation.

Collectively, these may offer opportunities to improve the extent to which

TWIF can support the CPS and Police‟s ongoing move to full electronic

digital working, though their absence is not currently compromising live

operation to any significant extent.

Whether any of these are taken forward to implementation depends on

collective agreement between the police forces and the CPS, available

funding and relative prioritisation against other business and IT issues

within those organisations.

I.2 Catalogue

Ref Title Description

1 BS7666

Addresses

Inconsistency between use of different industry standards to

maintain address data in CMS and police systems leads to

problems in maintaining a common view of addresses across

those systems and potentially repeated manual editing of them.

2 Greatest Needs

and Vul/Int

„Greatest Needs‟ is a witness flag that can be set in CMS but

not chosen to be received by the police, via the Appendix D.3

data. If set, then a vic/wit can‟t be marked as vul/int in CMS

and any attempt to do so by an LM04u will be ignored. Return

WM01u messages will show vul/int flags unset, contrary to

the police‟s view, but without visibility of the fact that GN has

been set instead. WCUs may also benefit from the police

being able to declare this, if a common understanding of what

it means can be reached.

There is also a related issue that an inconsistency in the

internal CMS specification documents for TWIF means that if

Vul/Int flags are set on an LM04u for a person who is marked

as a pure witness they are ignored on CMS and not applied.

This is probably wrong and the flags should be allowed for

people who are pure victims, pure witnesses or victims and

witnesses. This is not an interface issue per se, but a probable

fault with CMS.

3 Appeal Case

Messaging

CMS maintains separate cases with the same URN for appeal

and charge cases but the police maintain just one case when

the defendant appeals. The bi-directional exchange of

messages in this scenario was never fully resolved in the

analysis phase and in live operation messages are only ever

routed between police systems and the CMS charge case, for a

given URN. Some limited form of information exchange may

however be useful between the appeal case and police systems

but rules would need agreeing to determine which CMS case a

police message with a given URN should be applied to and

how independent updates made on the CMS charge and appeal




250

cases to witnesses, defendants, charges etc common to both

should be notified to the police.

4 Further

Enquires

When a proposed charge adjudication decision of „further

enquiries‟ is given, there are inconsistent views between the

police and the CPS as to whether a further consultation would

be performed to address the FE offence given the overall

suspect decision would already have been reached. Thus a

subsequent CM02 may not be received and police systems

may need to be able to manually declare the final status of a

previously declared FE proposed charge.

Note: if such a charge is eventually put to the defendant, CMS

is still able to accept notification of that on a CM03.

5 Lost Updates As described in Appendix H.4.5, depending on how WM01u

messages are processed, police systems and CMS may end up

with inconsistent views of witness data which could

eventually compromise some aspect of the case progression.

In areas where this occurs more discussion may be beneficial

to fully understand the impact and identify any potential

changes to the business processes and IT behaviour.

(Note: the same issue could also exist with defendant updates

on the DM01)

6 OiC The Sep 2011 WG discussed the idea of adding Officer In

Case and CJU Contact details to the CM01, CM03 and LM01

messages.

CMS actually maintains separate information on up 11

different types of police contact and the police station and has

complex logic built in for how this is all maintained in its

users interface and the existing v1 and v2 ExiSS messages.

Any attempt to add more contact data must be considered

within the framework of how CMS operates. This analysis is

outstanding and the messages haven‟t been altered in this

respect, although there may still be business benefit in

progressing the ideas. Further details are in this mail:

.

7 LM01 updates When a case is manually registered in CMS receipt of an

LM01 doesn‟t register a duplicate case, but does mark the

existing one as TWIF enabled allowing it to nominally partake

in messaging. However, the LM01 cannot currently update

any data on the manually registered case.

Allowing this (through name matching and other techniques)

may be beneficial as it could enable the defendants, charges

and other fragments of case data with Unique Ids to be

„upgraded‟ to their electronic equivalents held on police

systems allowing them to fully participate in subsequent

messaging.

8 Police

witnesses

If a police witness is updated in CMS, the agreed process is

that a WM01u message is not sent to the police as the police

are deemed the data owner and reserve the right to be able to

ignore any update from the CPS for their witnesses.

However, there is nothing in the interface definition that

prevents CMS from creating a police witness and informing

the police of this on a WM01 message; nor of either side

changing the witness flags to mark/un-mark an existing

witness as a police witness. It might be argued this is logically




251

inconsistent, as is the ability for CMS to delete a police

witness – discussed at the end of section 5.1.7.2.2.

10 Inchoate

offences

During the analysis phase, the WG discussed the problem of

PNLD not holding all inchoate forms of each substantive

offence and how the police systems and CMS should

communicate these to one another when the need arises. A full

business process was never agreed in this area and it remains

unclear what differing solutions each force has to this problem

and exactly what interaction these cause with CMS, though it

is believed use of the generic uncoded offences may be

prevalent.

11 Witness

reactivations

During the analysis phase, the WG never fully defined the

process by which deleted witnesses would be reactivated if it

was subsequently concluded they were needed on a case,

though reference is made to this in section 5.1.7.2.2. When

witnesses are asymmetrically deleted because one side

rejected the deletion the BPD states that update messages will

be ignored.

In fact, it may be better if they were always applied to the

deleted witness then on any subsequent reactivation the

witnesses would be synchronised across police systems and

CMS. This is probably a rare scenario but the benefits, and

potential impact, of this could be explored further.