cjse-related data standards - wiki · cjse data standards catalogue guidance v4.1 271006 1...

CJSE-related Data Standards Data Standards Catalogue Guidance Version 4.1

Document Control

Owner Bill Mclennan (replacing Ian Hardy and Linda Minns) Author Gareth Turpin Version 4.1 Status Approved Issue History

Date Version Changes Summary 13th August 2004 0.1 Initial draft 24th August 2004 0.2 Changes following first

internal review 14th October 2004 1.0 Changes following review by

CJOs 15th November 2004 1.0.1 New issue to accompany

version 2.0 of the DSC 20th December 2004 2.0 Changes following internal

review 3rd August 2005 2.1 New issue to accompany

version 3.0 of the DSC 8th August 2005 2.2 New issue to accompany

version 3.0 of the DSC (replaces 2.1)

2nd September 2005 2.3 Changes following internal review

28th September 2005 3.0 Changes following internal review

27th September 2006 4.0 New issue to accompany version 4.0 of the DSC

27th October 2006 4.1 New governance process diagram added. Structure to element relationship diagram added. New RFC process diagram created. Version control section changed.

Circulation List

Name Organisation Date Brian McCartney ACPO 27th October 2006 Martin Cox CJIT / DCA 27th October 2006 Steve Walmsley CPS 27th October 2006 Jim Kerfoot CPS Supplier 27th October 2006 Daryl Linabury DCA 27th October 2006 Donna Bolton DCA 27th October 2006 Geoff Winton DCA 27th October 2006 Helen Locke DCA 27th October 2006 Ian Budd DCA 27th October 2006 Lynda Minns DCA 27th October 2006

CJSE Data Standards Catalogue Guidance v4.1 271006

Nigel Pepper DCA 27th October 2006 Paul Backhouse DCA 27th October 2006 Stella Olatidoye DCA 27th October 2006 Neil Howell Hampshire Police 27th October 2006 Julie Hincks HMPS 27th October 2006 Graeme McCabe Home Office 27th October 2006 Diane Richards Kent Police 27th October 2006 Anne Kennedy Lancashire Police 27th October 2006 George Flanagan Lancashire Police 27th October 2006 Ian Pickard MPS / PNC 27th October 2006 Roger Thomas Niche Technology 27th October 2006 Aled Roberts North Wales Police 27th October 2006 Caroline Morrell North Yorkshire Police 27th October 2006 Andy Simister PITO 27th October 2006 Brian Shanks PITO 27th October 2006 David Skellern PITO 27th October 2006 Hannah Turner PITO 27th October 2006 Helen Mylam PITO 27th October 2006 Jackie Allen PITO 27th October 2006 Nicholas Lear PITO 27th October 2006 John Frosztega RDSD 27th October 2006 Hamish Wilkie Steria 27th October 2006 Silas Lawrence Steria 27th October 2006 Richard Moulton Vivista 27th October 2006 Dick Harlow West Yorkshire Police 27th October 2006 Margaret Dean YJB 27th October 2006

Page 1 of 21


Glossary of Acronyms ASN Arrest/Summons Number CJIT Criminal Justice Information Technology CJO Criminal Justice Organisation CJS Criminal Justice System CJSE Criminal Justice System Exchange CPR/s Criminal Prosecution Reference/s CPS Crown Prosecution Service CRO Criminal Records Office CV Constrained Value/s DCA Department for Constitutional Affairs DS Data Standards DSC Data Standards Catalogue HO Home Office OU Organisation Unit (previously CJO OU) SOW MG Standard Offence Wording Management Group SOW WG Standard Offence Wording Working Group © Crown Copyright 2006 This material is subject to Crown copyright protection unless otherwise indicated. The Crown copyright protected material (other than the departmental logos) may be reproduced free of charge in any format or medium provided it is reproduced accurately and not used in a misleading context. Where any of the Crown copyright items are being republished or copied to others, the source of the material must be identified and the copyright status acknowledged. The permission to reproduce Crown protected material does not extend to any material which is identified as being the copyright of a third party. Authorisation to reproduce such material must be obtained from the copyright holders concerned.

Page 2 of 21


1 INTRODUCTION 4 1.1 BACKGROUND 4 1.2 DATA STANDARDS GOVERNANCE 5 1.3 DATA STANDARDS CATALOGUE STRUCTURE 6 1.4 STATIC AND DYNAMIC DATA 7 1.5 REQUEST FOR CHANGE PROCESS 8 1.6 DATA STANDARDS CATALOGUE VERSION CONTROL 9 1.7 DOCUMENT COMMENTS 9

2 CRIMINAL PROSECUTION REFERENCE 10 2.1 CRIMINAL PROSECUTION REFERENCE DATA STRUCTURE 10

3 ORGANISATION UNIT 12 3.1 ORGANISATION UNIT DATA STRUCTURE 12

4 OFFENCE FIXED 12 4.1 OFFENCE CODES 12 4.2 OFFENCE CODE FIXED DATA STRUCTURE 12

5 OFFENCE VARIABLE 13 6 RESULT FIXED 13

6.1 RESULTS CODES 13 6.2 RESULT CODE FIXED DATA STRUCTURE 13

7 RESULT VARIABLE 13 8 RESULT QUALIFIER FIXED 13

8.1 RESULT QUALIFIER CODES 13 8.2 RESULT QUALIFIERS DATA STRUCTURE 14

9 RESULT QUALIFIER VARIABLE 14 9.1 RESULT QUALIFIER CODES 14 9.2 RESULT QUALIFIERS DATA STRUCTURE 14

10 PERSON 14 10.1 NATIONAL INSURANCE NUMBER 14 10.2 PERSON NAME SEQUENCE 14 10.3 UK ADDRESS 15 10.4 COUNTRY AND PERSON STATED NATIONALITY 15 10.5 ETHNICITY 15 10.6 PERSON REMAND STATUS 16 10.7 ROLE, ORGANISATION AS A DEFENDANT ETC. 17

11 SYSTEM ID 19 12 CASE AND HEARING DETAILS 19 13 THE PROGRESS APPLICATION 20 14 THEMATIC FLAGGING 20 15 APPENDICES 21

15.1 APPENDIX ONE – REQUEST FOR CHANGE PROCESS MODELLING NOTATION 21

Page 3 of 21


1 Introduction

1.1 Background This document contains guidance to the CJSE-related Data Standards Catalogue (DSC) version 4.1 and is designed to support usage of the DSC. In particular it explains the structure and inter-relationships between Data Elements. As such it is recommended that this Guidance document is treated as an accompaniment to the DSC. The CJSE-related Data Standards Forum requested this Guidance document to facilitate the understanding of:

− The difference between “fixed” and “variable” data structures − The difference between static and dynamic data − Explanatory details about the mapping of certain constrained values in one Data

Element with certain other constrained values in another Data Element e.g. Ethnicity − To provide Guidance on other aspects of DSC usage as appropriate

Page 4 of 21


1.2 Data Standards Governance

Page 5 of 21


1.3 Data Standards Catalogue Structure The Data Standards Catalogue has two main sections. Section 2.1 represents the complete list of agreed data structures. A data structure can be thought of as a logical grouping of individual data elements. Section 2.2 of the document comprises a complete list of all agreed data elements in alphabetical order. An example of how structures relate to elements is represented in Figure 2 below, using the example of the data structure Criminal Prosecution Reference which is comprised of the elements Defendant or Other, Offence Reason and Offence Reason Sequence. For ease of use both the data structures within section one and the data elements within the second section are cross referenced accordingly using ‘is part of’ and ‘has parts of’ respectively. To navigate through the catalogue more easily hyperlinks / anchors have been used within the ‘is part of’ and ‘has parts of’ fields, which are activated by using CTRL and left mouse clicking upon the structure or element in question.

Page 6 of 21


1.4 Static and Dynamic Data Static Data – Refers to data where the values are fixed and limited to a specified set of particular values. Any component of a Structure or Element where there are a restricted list of values can be considered to be static. An example of static data within the Data Standards Catalogue is the Element ‘England and Wales Indicator’ which belongs to the Result Fixed Structure. The permitted values within the values field are:

− Y = Yes (the Result only applies to England and Wales) − N = No

And therefore can be considered to be static data. Dynamic Data – Refers to data where the values are not fixed to a preordained set of values. Although limitations may be placed upon the format and structure of the data such as maximum of 120 characters and that it must be alphanumeric. Any component of a Structure or Element where there are not a fixed set of preordained values can be considered to be dynamic. An example of dynamic data within the Data Standards Catalogue is the element ‘Person Name’, belonging to the Person structure. A ‘Person Name’ instance can be any combination of alphanumeric characters to a maximum of 35 and with no spaces and therefore can be considered to be dynamic data.

Page 7 of 21


1.5 Request for Change Process Figure two below represents the request for change process. Please refer to Appendix One for an explanation of the modeling conventions used.

Page 8 of 21


1.6 Data Standards Catalogue Version Control Version control of the Data Standards Catalogue is managed at three levels:

− Catalogue − Structure − Element

All three levels were initially baselined at version 1.0, corresponding to the initial version of the Catalogue. Structures and Elements both have a version number and previous version number. The rules for populating version and previous version fields are as follows: Version: Populated to identify the version of the Catalogue in which it was first introduced or the version of the Catalogue in which it was updated. Previous Version: In the instance that the structure or element has been updated in a new version of the catalogue this field should be populated to refer to the last version of the DSC in which the structure of element was present before an update was made to it.

1.7 Document Comments The Data Standards Team welcome comments on the content of this Guidance Document and of the Data Standards Catalogue via email to [email protected].

Page 9 of 21


2 Criminal Prosecution Reference 2.1 Criminal Prosecution Reference Data Structure Introduction Two-way automatic communication between systems requires unambiguous indexing of the core entities which underpin the information to be exchanged between them. For CJO case management systems sharing information through the CJS Exchange, these core entities have long been accepted as defendants/offenders and the offences (or other “reasons” for their appearance) linked to them: with other CJO identifiers mapped to them in turn: e.g. person identifiers, case identifiers and crime reference identifiers. So, a permanent unique reference common between the Exchange and connected case management systems has been agreed by CJOs to identify a linked defendant/offender – offence/reason “pair”. CPR Structure In essence this is a generic extension of the ASN (Arrest Summons Number)/sequenced CJS Offence Code structure designed to cover the common indexing of all shared criminal case-related information within case preparation and prosecution processes, and within relevant offender management processes. The structure is outlined below and is described in full in the DSC. It is based on the main existing case preparation/prosecution route into the Courts – which identifies a defendant/offender by a Police Service standard Arrest Summons Number (ASN), linked to a CJS standard offence code (sequenced against the ASN for uniqueness). One or more of these linked references are then allocated within a case identifier (a PTI_URN). The usage of the structure of these linked references can be extended to identify these elements generically for all cases into the Courts. This “Criminal Prosecution Reference” (CPR) can then be used to track these linked elements through the process, to map to CJO equivalents (if necessary) and to case identifiers, and to enable automatic resulting. A “real person” can be linked to one or more CPRs where a PNCid is available (validated through fingerprinting and a resulting CRO number), as can potentially a reference for on-line tracking by victims, witnesses and others, or an incident/crime reference for management information purposes. The Exchange concept of sharing case-related information through linked systems will not work without a common reference. The structure of a permanent unique common reference to describe a criminal prosecution (i.e. a Criminal Prosecution Reference (CPR)) identifies the following: core information underlying the case preparation, prosecution process and offender management; a defendant or offender (defendant/offender) in a case; an offence/ reason for the defendant/offender being in the case. The CPR consists of three linked elements: a) defendant/offender element b) offence/reason element c) offence/reason sequence element a) Defendant/Offender Element

Page 10 of 21


This element identifies the instance of a person or organisation (i.e. an organisation being prosecuted) as a defendant/offender in a case. b) Offence/Reason Element This element identifies the offence or equivalent reason for a defendant/offender being in a case. This is the format of the CJS Offence Code Data Standard. c) Offence/Reason Sequence Element More than one identical offence/reason can be linked to a defendant/offender in a case. A sequence number is therefore required to distinguish between them and ensure the uniqueness of the three-element CPR (i.e. N(3) – 001-999). This is applied to all offences/reasons within a defendant/offender. Once allocated, a CPR must be permanent (i.e. not re-used). Related CJSE-related Data Standards Work CJIT is now looking at CPR implementation issues across the CJOs (e.g. the Magistrates’ Courts resulting to PNC) in the context of linking strategic case management systems through the CJS Exchange. This work is intended to support each CJO in their own development of their strategic case management systems, taking the Exchange and common referencing into account. On-going ownership and management of the structure and format of the standards for the CPR defendant/offender and offence/reason elements is carried out by the CJIT Data Standards Work Stream on behalf of CJS IT Governance through the cross-CJO CJSE-related Data Standards Forum.

Page 11 of 21


3 Organisation Unit 3.1 Organisation Unit Data Structure OU Codes are allocated by the CJIT Data Standards Work Stream on behalf of CJS IT Governance through the cross-CJO CJSE-related Data Standards Forum, except where specified. At the “OU Code Third Level” joint units will be coded by each participating CJO (e.g. the CPS and the Police will each have their own codes for a Police/CPS Criminal Justice or Trial Unit, where codes are allocated). At the “OU Code Bottom Level” the DCA (Magistrates’ Courts) have delegated responsibility for their Court Room codes, to be allocated at Area level in liaison with the Area’s Police Force and CPS. The Prison Service (within the National Offender Management Service) has delegated responsibility for their Prison Sub-Establishment codes, allocated at national level. OU codes for legal practitioners (solicitors and barristers) are coded a follows:

− OU Code Top Level : “I” − OU Code Second Level: The first two characters of the postcode − OU Code Third Level: Two characters uniquely identifying a firm within the OU Code

Second Level i.e. the postcode first two characters of the postcode − OU Code Bottom Level: Two characters uniquely identifying an office (a branch)

within the OU Code Third Level i.e. the firm

4 Offence Fixed 4.1 Offence Codes Offence Codes are allocated by the Police National Legal Database (PNLD) on behalf of CJS IT Governance through the cross-CJO CJSE-related Data Standards Forum and the Standard Offence Wording Management Group.

4.2 Offence Code Fixed Data Structure The static data within the Offence Codes fixed section is part of the Data Standards managed by the CJSE-related Data Standards Forum. The values used (the Dynamic Data) e.g. the actual Offence Codes, Standard Offence Wording, the setting of which CV for which Offence Code etc are managed by the Standard Offence Wording Management Group (SOW MG) facilitated by CPS.

Page 12 of 21


5 Offence Variable The CJSE-related Data Standards Forum requested guidance on which Data Elements were at Case and/or Hearing level and which were at Offence level (where a Case is referred to as being a Case against a single defendant). This was to assist the development of systems and interfaces between systems e.g. the Case level Data Elements need not necessarily repeat for all Offences within a Case. It is not the intention to influence the design of Offence data structures within systems and system interfaces by the structures given within the DSC, however where a Data Item is exchanged between CJOs that Data Item must adhere to the Data Standard within the DSC. Case and/or Hearing Level Data Elements are those that have the same value across various Offences within a particular Case. These are in different sections of the DSC – Case and Hearing.

6 Result Fixed 6.1 Results Codes Results (and Result Qualifier) Codes are allocated by a Sub-Group of the cross-CJO CJSE-related Data Standards Forum on behalf of CJS IT Governance. The Sub-Group is known as “The Results Sub-Group”.

6.2 Result Code Fixed Data Structure The static data within the Result Codes fixed section is part of the Data Standards managed by the CJSE-related Data Standards Forum. The values used (the Dynamic Data) e.g. the actual CJS Result Codes, Result Descriptions, the setting of which CV for which CJS Result Code etc is managed by the Results Sub-Group of the CJSE-related Data Standards Forum.

7 Result Variable A “result” is viewed as the result of a hearing of an offence against a single defendant. A “result” may include the adjudication, remand status, court type etc i.e. the “whole result” or may be individual components of the whole result e.g. a fine, compensation, costs, period of sentence etc. (known as “disposals” in police terminology). The DSC includes a single section of “actual” Result Code Data Elements but does not differentiate between those Data Elements that appertain to the “whole result” and those that appertain to an individual “component result” that is a component of the “whole result” e.g. costs. The DSC does not purport to influence the process design within CJO applications or the interfaces between them, certain Data Elements within the Result Codes Data Structure repeat for each “component result” and applications may be designed to remove that repetition, however where a Data Item is exchanged between CJOs that Data Item must adhere to the Data Standard within the DSC.

8 Result Qualifier Fixed 8.1 Result Qualifier Codes Result Qualifier Codes (and Result Codes) are allocated by a Sub-Group of the cross-CJO CJSE-related Data Standards Forum on behalf of CJS IT Governance. The Sub-Group is known as “The Results Sub-Group”.

Page 13 of 21


8.2 Result Qualifiers Data Structure Each Result may have a number of Result Qualifiers which provide further details of a result. In the result Qualifiers Fixed DS these are known as Result Applicable Qualifier Code and repeat, they are static Data Elements within the fixed part of the Result Data Structure.

Result Qualifier Code referred to above is an instance of an actual result (i.e. variable data) selected from Result Applicable Qualifier Code in the fixed data.

The DSC includes Data Elements to allow a Result Qualifier to have Durations, Dates and Text in a similar way to a Result having Durations, Dates and Text. This is to accommodate requirements of the Criminal Justice Act. At the time of production of DSC Version 3.0 it was felt unlikely that Result Qualifiers will have more than one Duration, Date and Text but the amended Data Standard allows for many for two reasons: Consistency with the Results Data Standard Flexibility for future expansion

9 Result Qualifier Variable 9.1 Result Qualifier Codes Result Qualifier Codes (and Result Codes) are allocated by a Sub-Group of the cross-CJO CJSE-related Data Standards Forum on behalf of CJS IT Governance. The Sub-Group is known as “The Results Sub-Group”.

9.2 Result Qualifiers Data Structure Each Result may have a number of Result Qualifiers which provide further details of a result. The whole

Result Qualifier Code referred to above is an instance of an actual result (i.e. variable data) selected from Result Applicable Qualifier Code in the fixed data.

10 Person

10.1 National Insurance Number One of the Person Data Elements shown in the DSC is National Insurance Number (NI No) it has been reported to the CJSE-related Data Standards Forum that there may be a need to seek permission from the Department for Work and Pensions before using the National Insurance Number as an identifier in an application.

10.2 Person Name Sequence This is a sequence number coupled with an instance of Person Given Name and/or Person Family Name to provide the correct sequence of individual names within the person’s “full” name. As a person may order their given name with their family name in various ways (depending on culture etc) the Person Name Sequence repeats with each Person Given Name and each Person Family Name. Person Name Sequence is mandatory for each Person Given Name and Person Family Name Each individual name of a person, whether the name is a given name or a family name, and regardless of the person’s religion or culture appears in a particular sequence. Person Name Sequence is a Data Element to identify the sequence of each component of a person’s full name. The Data Element is numeric and can be one or two digits in length, this allows a person to have between one and ninety nine components (given family and family names) to their full name. The following examples are offered to explain further: Simon Smith (where Simon is the given name and Smith is the family name): The Person Given Name is allocated Person Name Sequence 1 (Simon);

Page 14 of 21


The Person Family Name is allocated Person Name Sequence 2 (Smith); This gives a full name of Simon Smith (i.e. Simon is a member of the Smith family). Mohammed Ali (where Ali is the given name and Mohammed is the family name): The Person Given Name is allocated Person Name Sequence 2 (Ali); The Person Family Name is allocated Person Name Sequence 1 (Mohammed); This gives a full name of Mohammed Ali (i.e. Ali is a member of the Mohammed family). Hyphenated names should not be separated into individual names e.g. “Billie-Jo Zeta-Jones” has one given name and one family name. Some people have more than one family name and some of those are hyphenated and some are not, family names are deemed to be a single Data Item, a single Person Name Sequence (number) is therefore allocated to the family name: Jordan Peter Patterson Coulson (where Jordan and Peter are the given names and Patterson Coulson are the family names): The first Person Given Name is allocated Person Name Sequence 1 (Jordan); The second Person Given Name is allocated Person Name Sequence 2 (Peter); The whole Person Family Name is allocated Person Name Sequence 3 (Patterson Coulson); This gives a full name of Jordan Peter Patterson Coulson (i.e. Jordan Peter is a member of the Patterson Coulson family). As stated above each component of a person’s full name must be allocated a Person Name Sequence (number). Some people have only one name, this would normally be a Person Given Name: Madonna (where “Madonna” may have been taken as her real/legal name, perhaps by deed poll): The Person Given Name is allocated Person Name Sequence 1 (Madonna); There are no other names, therefore no other Person Name Sequence numbers are used.

10.3 UK Address This is the postal address of a person or organisation and does not include UK Postcode or Country, they are separate Data Elements. The address has a minimum of 2 lines and a maximum of 5 lines. If a foreign address the overseas post code/zip code will be present in one of the five lines. A value of “No fixed abode” is permitted but note that the standard has a minimum address of two lines

10.4 Country and Person Stated Nationality The Country Data Standard and the Person Stated Nationality Data Standard both use the ISO 3166 standard for an actual list of alphabetic codes and countries. The alphabetic code is the 3-char alphabetic code along with the short country name. This is the e-GIF “Country Code”, referred to here as “Country”.

Users are of this standard are informed that they can download the ISO 3166 standard by licence subject to payment of a fee. Alternatively a number of other web sites offer the list without registration or payment.

10.5 Ethnicity A number of ethnicity codes are in use around the Criminal Justice System, three are specified in the DSC:

Page 15 of 21


Ethnicity Self-Defined - the 16+1 codes as first used in the 2001 census, these values are specified by the person, it is not the opinion of any third party. This can be recorded for any person known to the system; Ethnic Appearance Observed 4+1 – the 4+1 codes used by some CJOs, it shows how a person “appears” to a third party e.g. a police officer. This is only used for defendants/offenders; Ethnic Appearance Observed 6+1 - the 6+1 codes used by some CJOs, it also shows how a person “appears” to a third party e.g. a police officer and is only used for defendants/offenders. A further Data Element to provide additional definition to a person’s own description of their ethnicity also exists: “Ethnicity Self-Defined Extra Definition” is a free text field for a person to add further definition e.g. Kosovan, Roma, Scottish etc. The full lists of values of the codes and literals is given in the DSC. It is possible to produce limited mapping between the three ethnicity codes. Mapping should not be performed from any “observed” value to a self-defined value, as the name suggests “Ethnicity Self-Defined” (the 16+1 list) is a person’s own definition of their ethnicity, any attempt to override that by mapping from an “observed” value could impinge their human rights. Ethnicity Self-Defined (16+1)

Ethnic Appearance Observed 4+1 Ethnic Appearance Observed 6+1

British Irish Any other white background

White

White - North European White - South European

White & Black Caribbean White & Black African White & Asian Any other mixed background Chinese Any Other

Other

Chinese, Japanese or any other South East Asian Arabic or North African

Indian Pakistani Bangladeshi Any other Asian background

Asian

Asian

Caribbean African Any other Black background

Black

Black

Not Stated Not recorded/Not known Not recorded/Not known

10.6 Person Remand Status Person Remand Status is used to reflect the overall remand status of the person rather than his/her remand status due to a particular offence result.

For Crown Courts this is the only means of indicating the person’s remand/bail status, because remand/bail is not set at individual offence level.

For Magistrates Courts this data item, if populated, summarises the person’s remand status following a hearing and it is the responsibility of the court to ensure that its value is consistent

Page 16 of 21


with the remand status held for each individual offence and that it is updated in line with offence-level remand statuses (Offence Remand Status in the Result Section show above).

This has been requested to set the remand status against a person in addition to being against individual results at the offence level. Individual CJO applications may set this Data Item automatically by taking the most serious remand status from all offence results for the defendant/offender. Care should be taken in circumstances where many offences/offence results were published against a defendant/offender but only one offence result carried a remand in custody status. If that offence was then withdrawn the defendant/offender could then have a bail remand status allowing him/her to be released.

10.7 Role, Organisation as a Defendant etc. A major change from version 3.0 of the DSC is in the area of “personal details”. Version 3.0 had a DS called Personal Details which included Role, Organisation etc. Version 4.0 has rationalised this to separate Person from Organisation and introduced Role and Contact Details. This diagram shows the relationship between data structures within the DSC but does not mandate entity relationships or data modelling required for any IT application:

Role

Contact Detail

Postal Address

Telephone Email

Person Organisation

DX Address

Defendant/Offender Witness etc

Person Family Name Person Birth date Person gender etc

DX Number DX Exchange

UK Telephone Number Telephone Number Type

Email Address Email Address Type

UK Address UK Post Code Country

Organisation Name Companies House Reference Number etc

Figure 4: Personal Details Structure The following lists show which Data Items are within which structures following the split of version 3.0’s Personal Details data structure: “D” indicates that the data item is only relevant when Role = Defendant/Offender Contact Detail No specific data items DX Address DX Number DX Exchange Email Email Address

Email Address Type

Page 17 of 21


Organisation Organisation Name D

Companies House Reference Number D

Person Arrest Summons Number (optional to ID a person) D

CRO No (optional to ID a person) D

Driver No (optional to ID a person) D

NI No (optional to ID a person) D

NIR No (optional to ID a person) D

Passport No (optional to ID a person) D

PNCid (optional to ID a person) D

Police Worker Collar No (optional to ID a person)

NOMS Number (optional to ID a person) D

Person Name Type

Person Birth Date

Person Gender

Person Title

Person Name Sequence

Person Given Name

Person Family Name

Person Name Suffix

Person Requested Name

Driving Licence Type Code D

Driving Licence Issue Number D

Driving Licence Cpart Issue No D Ethnicity Self Defined D

Ethnicity Self Defined Extra Def D

Ethnic Appearance Observed 4 plus 1 D

Ethnic Appearance Observed 6 plus 1 D

Language Requirement

Specific Requirements

Security Remarks

Religion

Person Notes

Person Remand Status D Vehicle Operator's Licence Number D Perceived Birth Year D Offender Code D Occupation Occupation Code Police Officer Rank Description Police Officer Rank Input Code

Page 18 of 21


Police Officer Rank Numeric Code Person Sated Nationality Postal Address UK Address

UK Postcode

Country

Role Role

Telephone UK Telephone Number

Telephone Number Type

No longer needed Organisation Indicator

Person ID

Person ID Type

11 System ID System ID is used to identify sender and recipient systems which send and receive messages via the CJSE hub. The CJSE maintains a list of systems which are allowed to connect, against which all incoming requests are validated. CJO applications (or their interface implementations) therefore need to be aware of the System ID for their system, and any System IDs of CJO applications which they wish to send messages to via CJSE. The System ID is partly based on the OU Code but also includes a system name e.g. MCS and the instance of that system within the OU e.g. B62MCS001 (i.e. allows for more than one MCS within area B62). System ID also has a start and end date to identify which systems are valid at a specific time. This also means that a CJO can replace a system with another with a period of dual running e.g. a police force could have its legacy case management system from 1st January until 31st December but cuts over to NSPIS Case Prep on 1st December with one month’s dual running. For the period 1st December until 31st December the force would have two valid System IDs.

12 Case and Hearing Details The CJSE-related Data Standards Forum requested guidance on which Data Elements were at Case and/or Hearing level and which were at Offence level (where a Case is referred to as being a Case against a single defendant). This was to assist the development of systems and interfaces between systems e.g. the Case level Data Elements need not necessarily repeat for all Offences within a Case. It is not the intention to influence the design of Offence data structures within systems and system interfaces by the structures given within the DSC, however where a Data Item is exchanged between CJOs that Data Item must adhere to the Data Standard within the DSC.

Page 19 of 21


Case and/or Hearing Level Data Elements are those that have the same value across various Offences within a particular Case. New in Version of the DSC is Case details and split apart from Hearing details i.e. they are two separate Data Structures.

13 The Progress Application The Progress Application (previously known as the Case Progression Tool (CPT)) required a number of new Data Standards. These are included as follows:

− Direction Fixed: A list of values for court directions, each one will be a CJS Result Code

− Progress Direction Variable: The actual court directions made − Progress Staff: Details of the case progression officer e.g. in CPS and in Courts − Progress Application: Details of actual applications to create or amend a direction − Progress Defendant: Details of an actual defendant in a trial

These Data Structures are only for use by Progress and its interface partners (CPS and Courts).

14 Thematic Flagging A new Data Structure introduced into the DSC Version 4.0 is Thematic Flagging. These are thematic codes to enable the recording of themes which may be used to calculate quantities of cases and/or person and/or offences of like themes for Management Information purposes and may also be used to mark a case, person or actual offence for operational purposes.

Page 20 of 21


15 Appendices

15.1 Appendix One – Request for Change Process Modelling Notation

Figure 5: Process Modelling Notation

Page 21 of 21

cjse-related data standards - wiki · cjse data standards catalogue guidance v4.1 271006 1...

Documents