Upload
ngokhanh
View
225
Download
0
Embed Size (px)
Citation preview
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:
© 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.
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
4
I.1 Introduction ....................................................................................... 249
I.2 Catalogue .......................................................................................... 249
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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;
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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).
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Decision for the suspect in the PCD Consultation, therefore an
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
Decision for the suspect in the PCD Consultation, therefore an
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
47
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
decide further investigation is
required. An action plan is
drawn up.
Pre-charge decision sent to
the Police.
The police carry out the
further investigation and
enter it onto their system.
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.
CM03: Charge Information
Case proceeds as an ordinary
charge case.
Submit a further pre-
charge decision request
A second 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
Figure 2 - A Pre-charge Decision Scenario Requiring Further
Investigation
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
49
Police CPSPolice prepare case
material for a case with
two suspects.
Submit a pre-charge
decision request
Case registered on CMS
Suspects added to case
Pre-charge decision request
created for suspects
CM01: Pre-charge Decision Request
Police officer and duty
prosecutor discuss case and
decide that the two suspects
should be charged separately
Pre-charge decision sent to
the police.
CM02: Pre-charge Decision Response
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.
Charge information is sent
to CPS for the suspect on
the original case.
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.
CM03: Charge Information
Case proceeds as an ordinary
charge case.
Police receive the
decision.
Charge information is sent
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.
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.
LM01: Charge Information
Case proceeds as an ordinary
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
50
4.2.4 Merging The Suspects On Two Cases Into One Case.
This scenario shows the processes that occur when the Duty Prosecutor
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Pre-charge decision request
created for each case
3 * CM01: Pre-charge Decision Requests
Police officer and duty
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.
CM02: Pre-charge Decision Response
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
CM02: Pre-charge Decision Response
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
This scenario shows the processes that occur when the Duty Prosecutor
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
53
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
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.
CM02: Pre-charge Decision Response
Police charge the
suspects, book hearings
and generate offence
information.
Next hearings and put
charges recorded against
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
Pre-charge decision request
created for suspect.
CM01: Pre-charge Decision Request
Charge information sent to
CPS
4.2.6 „Not Given for This Suspect‟ Consultation
This scenario shows the processes that occur when the Duty Prosecutor
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
CM02: Pre-charge Decision Response
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.
Next hearings and put
charges recorded against
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
Pre-charge decision request
created for suspect.
CM01: Pre-charge Decision Request
Charge information sent to
CPS
Suspect C added to existing
case
Pre-charge decision request
created for suspect.
CM01: Pre-charge Decision Request
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.
CM02: Pre-charge Decision Response
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Sent in any order and as many times as needed
WM01 : New Witness
WM01u : Updated Witness
DM01 : Updated Defendant
FM02 : Case Action Plan
Sent in any order and as many times as needed
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Case registered on CMS
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
76
Ref Business Rule Applied by
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
77
Ref Business Rule Applied by
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
78
Ref Business Rule Applied by
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
79
Ref Business Rule Applied by
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:
Ref Business Rule Applied by
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
80
Ref Business Rule Applied by
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
88
Figure 14 - An expansion of the Alias element
Figure 15 - An expansion of the PNCId element
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
90
Figure 18 - An expansion of the ASN element.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
91
Figure 19 : An expansion of the Offence element within the Defendant
element.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
6.4.2 Summary of changes between version 1 and version 2
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
Sender Police IT System
Recipient Compass CMS
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.
6.4.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
Failure
LM02.1.1 Defendant with this unique Identifier and URN does not already
exist.
BE41
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
97
6.4.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
LM02.2.1 This message can only be sent from the Police to CMS.
LM02.2.2 This message can only be sent against a case which already exists on CMS, either through
manual or electronic registration.
6.4.6 Message Triggers
The following table indicates when an LM02 message can be sent:
Ref Source Trigger
LM02.3.1 Police New defendant added to a charge case in Police Systems.
6.4.7 Data
The data items carried by this message are specified in the following
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
6.5.2 Summary of changes between version 1 and version 2
This message is new in version 2.
6.5.3 Constraints
Constraint Value
Sender Police IT System
Recipient 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
Can cause registration No
How often As many times as required for each defendant
6.5.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
Failure
LM03.1.1 If present, the Parent/Guardian UniqueId must be unique within the
case
BE17
6.5.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
LM03.2.1 This message can only be sent from the Police to CMS.
LM03.2.2 This message can only be sent against a case which already exists on CMS and contains
the defendant to be updated.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
99
6.5.6 Message Triggers
The following table indicates when an LM03 message can be sent:
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
The data items carried by this message are specified in the following
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
6.6.2 Summary of changes between version 1 and version 2
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
Sender Police IT System
Recipient Compass CMS
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
102
Constraint Value
cautions.
Can cause registration No
How often Once for each victim or witness, As many times as required
for each case.
6.6.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
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
6.6.5 Message Sending Rules
The following rules will be validated before the message is sent:
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.
6.6.6 Message Triggers
The following table indicates when an LM04 message can be sent:
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
The data items carried by this message are specified in the following
diagrams.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
103
Figure 27 : The structure of the LM04 New Witness logical message.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
104
Figure 28 : The structure of the Person element within the LM04 New
Witness logical message.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
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.
Unlike the LM04 message, the new witness message from CMS to the
Police does not include any victim level offences.
6.7.2 Summary of changes between version 1 and version 2
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.
Can cause registration No
How often Once for each victim or witness, As many times as required
for each case.
6.7.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
107
6.7.5 Message Sending Rules
The following rules will be validated before the message is sent:
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.
6.7.6 Message Triggers
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
The data items carried by this message are specified in the following
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
The message can contain information for only one witness or victim. If more
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.2 Summary of changes between version 1 and version 2
This message is new in version 2.
6.8.3 Constraints
Constraint Value
Sender Police IT System
Recipient Compass CMS
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Can cause registration No
How often Once for each time a witness is updated. As many times as
required for each case.
6.8.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
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
6.8.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
LM04u.2.1 Witness or victim updated exists on the case and has not been deleted by CMS
6.8.6 Message Triggers
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
110
6.8.7 Data
The data items carried by this message are specified in the following
diagrams.
Figure 31 : The structure of the LM04u New Witness logical message.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
111
Figure 32 : The structure of the UpdatedPerson element within the
LM04u New Witness logical message.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
The message can contain information for only one witness or victim. If more
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.2 Summary of changes between version 1 and version 2
This message is new in version 2.
6.9.3 Constraints
Constraint Value
8 The WM01u message is not sent to the police for updates of a police witness on CMS.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
114
Constraint Value
Sender Compass CMS
Recipient Police IT System
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.
Can cause registration No
How often As many times as required. Once for each relevant update
on CMS.
6.9.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
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
6.9.5 Message Sending Rules
The following rules will be validated before the message is sent:
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.
6.9.6 Message Triggers
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
115
Ref Source Trigger
WM01u.3
.4
CPS CPS reject a police deletion of a witness or victim
6.9.7 Data
The data items carried by this message are specified in the following
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
6.10.2 Summary of changes between version 1 and version 2
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.
.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
117
6.10.3 Constraints
Constraint Value
Sender Police IT System
Recipient Compass CMS
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.
Can cause registration No
How often Once for each statement. As many times as required for a
witness and, therefore, a case.
6.10.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
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
6.10.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
LM05.2.1 This message can only be sent from the Police to CMS.
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.
6.10.6 Message Triggers
The following table indicates when an LM05 message can be sent:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
118
Ref Source Trigger
LM05.3.1 Police New Witness statement added to Police System.
6.10.7 Data
The data items carried by this message are specified in the following
diagram:
Figure 33 : The structure of the LM05 New Witness Statement logical
message.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
6.11.2 Summary of changes between version 1 and version 2
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
Sender Police IT System
Recipient Compass CMS
Must be sent after Any message that causes case registration, or manual case
registration
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
121
Constraint Value
Must be sent before Case finalisation on CMS, unless case was subject to asset
recovery or conditional cautions.
Can cause registration No
How often Once for each exhibit. As many times as required for a
case.
6.11.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
Failure
LM06.1.1 Message received for Exhibit with Unique Identifier that is not
already in use on the case as specified by the PTI-URN
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
6.11.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
LM06.2.1 This message can only be sent from the Police to CMS.
LM06.2.2 Each exhibit must be identified by a unique identifier at case level.
LM06.2.3 This message can only be sent against a case which already exists on CMS, either through
manual or electronic registration.
6.11.6 Message Triggers
The following table indicates when an LM06 message can be sent:
Ref Source Trigger
LM06.3.1 Police New Exhibit added to Police System.
6.11.7 Data
The data items carried by this message are specified in the following
diagram:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
6.12.2 Summary of changes between version 1 and version 2
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Must be sent after Any message that causes case registration, or manual case
registration
Must be sent before Case Finalisation on CMS, unless case was subject to asset
recovery or conditional cautions.
Can cause registration No
How often As many times as required for a case.
6.12.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
Failure
LM07.1.1 Message received for Document with Unique Identifier is not
already in use on the case as specified by the PTI-URN
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
6.12.5 Message Sending Rules
The following rules will be validated before the message is sent:
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
125
6.12.6 Message Triggers
The following table indicates when an LM07 message can be sent:
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
The data items carried by this message are specified in the following
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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).
6.13.2 Summary of changes between version 1 and version 2
The LM08 message has not changed between version 1 and version 2.
6.13.3 Constraints
Constraint Value
Sender Police IT System
Recipient Compass CMS
Must be sent after Any message that causes case registration, or manual case
registration
Must be sent before Case finalisation on CMS
Can cause registration No
How often At most once per case
6.13.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
Failure
LM08.1.1 Case for which message is received is not marked as having
received the Full File
BE9
6.13.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
LM08.2.1 This message can only be sent from the Police to CMS.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
127
Ref Business Rule
LM08.2.2 This message can only be sent against a case which already exists on CMS, either through
manual or electronic registration.
6.13.6 Message Triggers
The following table indicates when an LM08 message can be sent:
Ref Source Trigger
LM08.3.1 Police When the Police have sent the full file to the CPS
6.13.7 Data
The data items carried by this message are specified in the following
diagram:
Figure 37 : The structure of the LM08 Full File Sent Indication logical
message
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.2 Summary of changes between version 1 and version 2
This message is new in version 2.
6.14.3 Constraints
Constraint Value
Sender Compass CMS
Recipient Police IT System
Must be sent after Case Registered in CMS and defendant added to case in
CMS
Must be sent before Case finalisation on either system
Can cause registration No
How often As many times as required for each defendant.
6.14.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
Failure
6.14.5 Message Sending Rules
The following rules will be validated before the message is sent:
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).
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
6.14.6 Message Triggers
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
6.15.2 Summary of changes between version 1 and version 2
This message is new at version 2 of the interface.
6.15.3 Constraints
Constraint Value
Sender Police IT System
Recipient Compass CMS
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
132
Constraint Value
How often As many times as required.
6.15.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
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
6.15.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
CM01.2.1 This message can only be sent from the Police to Compass CMS.
6.15.6 Message Triggers
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.2 Summary of changes between version 1 and version 2
This message is new at version 2 of the interface.
6.16.3 Constraints
Constraint Value
Sender Compass CMS
Recipient Police IT System
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
Can cause registration on
Police IT System
No
How often As many times as required for a suspect.
6.16.4 Message Receipt Rules
The following rules will be validated when the message is received:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
142
Ref Business Rule Response on
Failure
6.16.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
CM02.2.1 This message can only be sent from Compass CMS to the Police.
6.16.6 Message Triggers
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.2 Summary of changes between version 1 and version 2
This message is new at version 2 of the interface.
6.17.3 Constraints
Constraint Value
Sender Police IT System
Recipient Compass CMS
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
Can cause registration on
Compass CMS
No
How often As many times as required.
6.17.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
152
6.17.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
CM03.2.1 This message can only be sent from the Police to CMS.
6.17.6 Message Triggers
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
153
Figure 53 -The structure of the Defendant part of the CM03
The, Offence and NextHearing are the same as seen in the LM01.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.2 Summary of changes between version 1 and version 2
This message is new at version 2 of the interface.
6.18.3 Constraints
Constraint Value
Sender Compass CMS
Recipient Police IT System
Must be sent after Any message that causes case registration, or manual case
registration
Must be sent before Case Deleted or Destroyed From CMS
Can cause registration No
How often As many times as required for a case.
6.18.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rules Response on
Failure
FM01.1.1
6.18.5 Message Sending Rules
The following rules will be validated before the message is sent:
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
155
6.18.6 Message Triggers
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
The data items carried by this message are specified in the following
diagram:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.2 Summary of changes between version 1 and version 2
This message is new at version 2 of the interface.
6.19.3 Constraints
Constraint Value
Sender Compass CMS
Recipient Police IT System
Must be sent after Any message that causes case registration, or manual case
registration
Must be sent before Case Finalised in CMS
Can cause registration No
How often As many times as required for a case.
6.19.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
Failure
FM02.1.1 All URNs specified in a merge case instruction are known to the police
system
BE35
6.19.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
FM02.2.1 This message can only be sent from CMS to the Police.
6.19.6 Message Triggers
The following table indicates when an FM02 message can be sent:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
The data items carried by this message are specified in the following
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.2 Summary of changes between version 1 and version 2
This message is new at version 2 of the interface.
6.20.3 Constraints
Constraint Value
Sender Police IT System
Recipient Compass CMS
Must be sent after Any message that causes case registration, or manual case
registration
Must be sent before Case deleted or destroyed from CMS
Can cause registration No
How often As many times as required for a case.
6.20.4 Message Receipt Rules
The following rules will be validated when the message is received:
Ref Business Rule Response on
Failure
6.20.5 Message Sending Rules
The following rules will be validated before the message is sent:
Ref Business Rule
FM02.2.1 This message can only be sent from the Police to the CMS.
6.20.6 Message Triggers
The following table indicates when an FM03 message can be sent:
Ref Source Trigger
FM03.3.1 Police The merging of two or more cases completes on the Police IT System. The
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
The data items carried by this message are specified in the following
diagram:
Figure 58 : The structure of the FM03 SplitMergeSynchronisation
logical message.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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‟.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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,
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
Decision PreChargeDecisionStructure Contains details of the pre-charge
decision(s)
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
178
CM03
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
Defendant Defendant Contains unique Id of the
defendant, details of their
offence(s) and of the next hearing.
DM01
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
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
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
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
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
179
(which is of type
PersonNameStructure).
FM03
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
LM01
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
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
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
Defendant DefendantStructure Contains details of the defendant
and charge information
LM03
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
180
LM04
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
Person BaseWitnessVictimStructure Contains details of an individual
who is a victim, a witness, or a
victim and a witness
LM04u
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
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
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
WitnessStatement WitnessStatement Contains WitnessId and Statement
AttachedDocument DocumentInformationStructure Describes an electronic witness
statement.
LM06
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
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
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
AttachedDocument DocumentInformationStructure Represents the electronic
document to attach to the case
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
181
LM08
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
WM01
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
Identifier
Person BaseWitnessVictimStructure Contains details of an individual
who is a victim, a witness, or a
victim and a witness
WM01u
Element Type Description
BaseItemStructure BaseItemStructure The unique Id of the item within
the business message and the case
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Base BasePersonStructure
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
Base BasePersonStructure
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Address AddressStructure
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
UniqueId UniqueIdType
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
Base BasePersonStructure
Firm Text (1-50)
CaseReference Text (1-30)
DeletedPersonStructure Container Complex Type comprising: Identifies the person to be
deleted Data Item Type
UniqueId UniqueIdType
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
UniqueId UniqueIdType
Name Text (1-255)
FileName Text (1-255)
Document base64Binary
ExternalFileURL Text
Username Text
Password Text
DocumentClassification ClassificationStructure
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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})
Year TwoDigitYearType
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
Address AddressStructure
ParticularsClassification ClassificationStructure
OffenceStructure Container Complex Type comprising: Holds all information
relating to an offence for a
specific defendant Data Item Type
UniqueId UniqueIdType
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Base BasePersonStructure
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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})
Year TwoDigitYearType
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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)
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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).
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
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.
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
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.
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
200
B.2 MG3 Page 2 Completed by the Duty Prosecutor
Figure 61 : The MG3 page 2.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
201
B.3 MG3A
Figure 62 : The MG3A.
Error! Unknown document property name./ Issue Error! Unknown
document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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}
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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)
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
New at version 2 Uses the following enumeration scheme:
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
New at version 2 Uses the following enumeration scheme:
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
New at version 2 Uses the following enumeration scheme:
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
226
P38 = Adequate compliance
P39 = Change in circumstances
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
© 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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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 ≡ ≡ ≡ ≡
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
236
Appendix G Offence Matching
Give Matching algorithm and justification for it
TBD (if necessary)
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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:
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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
Issue Error! Unknown document property name.
Error! Unknown document property name.
Two Way Interface - Business Process - v1.0
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.