Abstract
In the Netherlands an initiative has been started to promote the use of electronic information exchange between organizations in the Criminal Justice System. The initiative is intended to improve quality of documents exchanged and to allow cases to be handled in less time and with improved efficiency across the Criminal Justice value chain. This paper describes this initiative and outlines its use of several recent international standards for e-business and e-government integration: the ISO 11179, ebXML Business Process, Core Components and UBL NDR specifications. A recently completed project that developed specifications for 21 interactions involving 6 partners related to article 8 of the national road and traffic law, driving under the influence of a substance, is now being generalized to cover a much larger set of "routine" cases.
Keywords
Table of Contents
In the Netherlands, as in many other countries, Police, Prosecution Office, Courts of Justice and other organizations that constitute the Criminal Justice system have traditionally been highly autonomous organizations, especially on issues regarding ICT strategy, architecture, information management and application development. As a result of this, development of Criminal Justice information systems has traditionally been aimed at supporting the internal business processes of the organizations, with much less attention being paid to improving the collaboration with partners across the Criminal Justice value chain and therefore its end-to-end efficiency and quality. Consequently, while organizations in the criminal justice system are heavy users of IT for internal document and data processing, today the interchange of information between these organizations is still largely based on traditional means of communication involving fax, telephone and, crucially, large scale movement of (copies of) paper documents and dossiers.
In 2001, an initial pilot project for electronic data entry and interchange of dossiers between Police and Prosecution was performed in three regions. This system allowed Police staff to use an advanced graphical user interface to enter data related to a particular high-volume offence, driving under the influence of a substance (article 8 of the national road and traffic law) and to transfer this information as a structured XML document to the Prosecution, using a SOAP over SMTP transport interface. While this pilot project successfully demonstrated the benefits of electronic information exchange, the system developed could not be deployed nationally, one reason of which was the absence of a national standard for the interaction processes and of a formal specification of the minimal required (and any optional other) content, format and structure of documents exchanged between organizations. Both Police and Prosecution are internally organized in independent geographical organizations. Many arrangements on process and content issues were only agreed bilaterally between Prosecution districts and the associated Police districts. There are 19 Prosecution districts and 26 Police districts in the Netherlands.
During a strategic session in 2002 involving senior management of various organizations, it was decided to set up a national programme Electronische Berichtenuitwisseling in de Strafrechtsketen [ePV] with the mission to implement electronic information and message exchange in the Criminal Justice system, thereby enabling electronic workflows and (interaction) process management. Its goals are to:
Promote awareness of, and support for, electronic information exchange and interaction process integration across the value chain;
Increase the scope and volume of interaction processes supported by electronic information exchange;
Increase the number of organizations that are connected electronically to their partners in the Criminal Justice system;
Address electronic information exchange in a larger context of value chain integration and collaboration initiatives.
The programme was set up as a joint initiative between the various organizations and was designed to leverage the momentum generated by the success of the pilot project, which had helped build a strong business case for interchange of structured electronic documents across the criminal justice value chain.
The programme also turned out to be able to take advantage of new ICT developments within both Police and Prosecution towards national systems. Historically, the core business applications within these organizations were heavily customized for specific regional implementations. For instance, there are three Police business process systems in the Netherlands, but the production implementations of these systems in each of the 26 Police districts have been customized for the specific organization and are updated and extended independently. The newer ICT systems of Police and Prosecution are designed and developed to be deployed and maintained nationally instead of regionally. This requires uniform interaction processes and agreements on content and structure of documents that are valid for interactions between Police and Prosecution in all regions, thus greatly reducing the cost and complexity of automating these interactions using electronic information exchange.
The main motivation for exchanging electronic documents, as opposed to (printed or copied) paper documents, is a reduction of the end-to-end time to process a case, an improved (ability to automatically verify) quality of documents and improved efficiency. Specifically, the benefits are:
A lower number (and percentage) of case dismissals and requests for additional information;
Less need to enter the same case information more than once;
Faster routing and distribution of cases within the Prosecution;
Reduced preparation time for cases;
Easier determination of appropriate sentence
Some advantages can already be achieved by fairly low-cost and unsophisticated solutions involving unstructured electronic documents, such as sending case files in PDF or word processor formats. Such solutions have been developed and deployed successfully in some regions. The core business application developed for the Prosecution office includes electronic document storage and workflow management facilities and supports an intake process where all incoming documents are scanned, and then handled electronically. This is unnecessary if the document is transmitted as an unstructured electronic document. However, structured electronic documents offer important additional benefits.
Structured electronic documents can be subjected to some automated checks for completeness and correctness of information, thus improving the quality of case documents and reducing the need for the Prosecution Office to submit requests for additional information to the Police. A common desire by both Police and Prosecution is to reduce or eliminate such requests, as they take much more time to process.
Prosecution Office and other "downstream" organizations use a lot of case information first recorded by the Police. In the case of the Prosecution Office, the Office of Counsel for the Prosecution again enters that information manually in their systems as part of the intake of a new case. Once the Police are able to send the information as structured XML messages, that information can be loaded into the Prosecution's database automatically without manual intervention. Since the volume of cases handled annually is huge, even modest improvements (such as a few minutes clerical staff time per case) can result in significant efficiency gains.
An example of an even more advanced functionality is a recent initiative to integrate the intake of electronic documents with a Decision Support System (D.S.S) used for determining appropriate sentences for many common high volume offences [BOS/Polaris]. This system uses a decision tree of questions and answers that help Prosecution staff classify cases and determine appropriate sentences given national norms. For example, in the case of driving under the influence of a substance, relevant parameters include the level of alcohol in the suspect's blood, whether or not the suspect has previous convictions, or endangered others by driving recklessly. If all or as many of these parameters as possible are encoded in a structured XML format, the time to determine sentences can be reduced significantly.
As part of the programme, a number of projects have been set up, some of which are looking at defining specifications for electronic interactions between organizations for specific areas (such as a particular offence or category of offences). In general these projects complement internal system development projects of the individual relevant organizations in the Criminal Justice value chain. An example of this is a recently completed project that developed a national standard for exchange of case information related to the offence of driving under the influence of a substance. It delivered specifications for:
Interaction processes;
The electronic documents exchanged by these processes;
The data elements used as semantic building blocks for the interaction documents; and the
XML schema representation of document and data element definitions.
Other projects are supporting the programme by investigating specific areas (such as the use of digital signatures in the Criminal Justice system) or by helping the various organizations set up mechanisms to validate the results of the specification team(s).
The scope of the programme is limited to what it calls interaction processes, i.e. the exchange of information between actors to support the handling of a particular case along the Criminal Justice system. The internal processes and information systems each of the organizations internally uses to manage the flow of incoming and outgoing messages are explicitly out of scope. Even in the case of high volume routine offences, these interactions can be very complex, requiring rigorous analysis and formal specification. As an example, the project that looked into the interactions related to the offence driving under the influence of a substance identified more than six organizations and 21 different interactions. Many of these interactions have deadlines, are to be performed sequentially or in parallel, under certain conditions, etc.
The programme is very much interested in taking advantage of concepts, technology and standards developed in the e-business application area where they are applicable to the Criminal Justice situation. In standards and specification frameworks for electronic business, interaction processes are variously referred to using terms like public processes, partner interface process (PIP), business transactions and collaborations. RosettaNet is a well-known example of an organization that has developed a standardized set of PIPs for a particular industry, viz. the information technology, electronic components and semiconductor industry [RosettaNet]. Each of the PIP specification documents follows a standard template and table of contents. These documents describe the interaction at several levels, starting at the Business Operational View (BOV), moving down the Functional Service View (FSV) to the Implementation Framework View (IFV). These levels are defined in the ISO Open-EDI standard [ISO 14662].
In the case of RosettaNet only basic interactions in the form of a business request document and a(n optional) business response document are described. This means that only binary interactions (between two partners or partner types) are modeled and that any higher-level relations between such exchanges (e.g. a invoice presupposes a previous purchase, which in turn usually relates to an earlier quote) is not modelled explicitly. This higher-level structure is implicit in the organization of the PIPs in segments and clusters. Importantly, these descriptions separate data flow from message flow, as they identify reliable messaging as a separate framework layer that provides for technical acknowledgments and for a resending mechanism for lost messages and lost acknowledgments.
The ebXML framework builds on the RosettaNet model for specification of interactions. The Business Process Specification Schema (BPSS) model being developed by the OASIS ebXML Business Process TC [BPSS] extends the PIP concept in several interesting ways. It introduces a concept of a Binary Collaboration, which internally is composed of Business Transactions, which can be interrelated in a graph structure that encodes constructs like sequencing, conditionally selected alternatives and parallelism. A separate specification of ebXML, Collaboration Protocol Profiles and Agreements (CPPA) allows partners to set additional technical configuration properties for their bilateral interactions. Binary Collaborations can in turn be combined into Multiparty Collaborations.
As part of the programme on electronic information exchange in the Criminal Justice system in the Netherlands, the project that looked at the driving under the influence of a substance offence documented the interaction processes at several levels. The most detailed level, intended for the software development teams at the various organizations that will need to design or adapt their systems to support electronic communication, is currently specified using a document that is similar to the RosettaNet word processor template, but supports the BPSS distinction of Collaborations and Transactions. This means that sections are added to specify the transitions between Transactions within a Binary Collaboration and between collaborations in the larger Multi-Party context. The individual collaborations are documented using the UML diagramming techniques for BPSS described in the business process section of [ebXML Foundations].
Several issues were encountered in the course of this work. The complete landscape of information exchanges includes types of interactions not easily handled in a framework like BPSS. Phone and fax are in some situations acceptable alternatives to electronic documents, whereas BPSS is designed to manage electronic collaborations using electronic messaging. The ebBP team seems to be aware of this issue. Furthermore, in the Criminal Justice case some documents are necessarily paper documents because they need to be signed and because digital signatures are not yet legally accepted in the Netherlands in the Criminal Justice context. This means we need to model a parallel electronic and paper document flow. Legislation for the use of electronic signatures in the Criminal Justice system is now being prepared in the Netherlands.
The offence driving under the influence of a substance involves more than twenty interactions, many of which share common data elements. Expanding the scope to other offences and to support other interaction processes will further complicate this. During an earlier XML pilot project the following issues were encountered.
Consistency of XML Schema and Data Dictionary. In the pilot project, a data dictionary was created listing a.o. the core domain concepts, their definitions, data types and source (relevant standard or standards organization). Many of these data elements were also defined in the XML schema. This resulted in a serious maintenance problem, as the life cycle of schema and data dictionary were hard to synchronize.
Multiple formats. Whereas new projects are generally adopting XML, some operational systems in the Criminal Justice system in the Netherlands use EDI syntax and future systems may use yet another format, e.g. formats that work better in limited bandwidth environments. It would be useful if the role and purpose of existing non-XML systems can be positioned in a broader context and if future or alternative formats can be supported easily.
In the absence of naming conventions for XML elements, different XML developers may propose incompatible names for XML elements even if they are working from the same basis (e.g. the same data dictionary). A consistent methodology is needed for naming, and the best way to ensure consistency is automation.
Feature set of XML Schema. W3C XML Schema (XSD) offers many additional features that XML Document Type Definitions lacks, such as a type system in addition to elements. As before, a consistent methodology is needed to make sure schemas are created in a consistent way, and again an easy way to ensure consistency is automation.
These considerations lead to a strong interest in the Core Component (business content) parts of ebXML, of which the OASIS Universal Business Language (UBL) is an implementation for XSD [UBL]. The Core Component and UBL specifications are based on ISO 11179, and have designed naming and design rules for XML based on Object Class (qualifier), Property (qualifier) and Representation term for XML data elements [ISO 11179]. The UBL work also includes guidelines on how to use the XSD typing system for XML data elements.
In the current phase of the programme, the project that developed the specifications for the driving under the influence of a substance offence has used a similar approach to the UBL TC for generating XML Schemas and even (provisionally) uses some of the tools used by the UBL TC to generate XML Schemas from spreadsheets in the absence of better development and maintenance tools and environments. Documents specifications are therefore specified using a spreadsheet format that adds information on cardinality on groups. They can also restrict or extend the number of elements in a group.
The data dictionary is currently a 169 page word processor document that uses a structured, predictable and highly consistent format for data element definitions. It consists not only of atomic elements but also provides some grouping of elements. The corresponding XML Schema file can be generated semi-automatically via the UBL TC's spreadsheet format using a combination of custom and OASIS UBL TC tools.
Note that only the naming and design parts of UBL are used here. The UBL Library for e-Commerce Business Information Entities is not used.
As the first project in the programme, the project on the offence driving under the influence of a substance recently delivered a set of specifications for interaction processes and specifications for about ten electronic documents. The original aim of that project was to then work with the relevant organizations to start implementation of these interactions. This plan has been changed and the current strategy is to first generalize and extend the scope of the current set of specifications to a larger set of "routine" offence types that accounts for a significant percentage of all case processed in the Criminal Justice system in the Netherlands . The results will be functional requirements for the partner interfaces of systems being developed by Police and Prosecution for delivery later this year.
The project team responsible for the work described in this paper includes Gerald Slot, Hugo den Hollander (Daidalos), Gerrit van de Ven and John Rassin (In-pact). The project team was supported by a large number of subject matter experts representing the various relevant organizations.
[BOS/Polaris] BOS systeem ter ondersteuning van de Polaris Richtlijnen (http://www.om.nl/bos/).
[BPSS] Business Process Specification Schema under development by the OASIS ebXML Business Process Technical Committee http://www.oasis-open.org/committees/ebxml-bp
[ePV] Programmaplan Electronische Berichtenuitwisseling in de Strafrechtsketen. Summary available via http://www.e-PV.nl/
[ePV artikel 8 WvW] Project Landelijke Uitrol Gestandaardiseerd ePV Artikel 8 WvW. Summary available at http://www.e-pv.nl/programma/onderdelen/a.html
[ePV Routinezaken] Project Specificatie Berichtuitwisseling Routinezaken. Summary forthcoming at http://www.e-pv.nl/
[ISO 14662] ISO/IEC Open-EDI Reference Model. http://www.iso.ch/
[ISO 11179] ISO/IEC Specification and standardization of data element. http://www.iso.ch/
[RosettaNet] Understanding a PIP Blueprint. RosettaNet User's Guide.http://www.rosettanet.org/.
[UBL] The OASIS UBL (Universal Business Language) Technical Committee (http://www.oasis-open.org/committees/ubl).
  |
Design & Development by deepX Ltd. |
