Digital procedural standard for the digitalisation of Directive 2014/41/EU
ANNEX VSupplementary provisions
ANNEX V Digital procedural standard for the digitalisation of Directive 2014/41/EU 1. Introduction and scope Article 3(9) of Regulation (EU) 2022/850 on a computerised system for the cross-border electronic exchange of data in the area of judicial cooperation in civil and criminal matters (e-CODEX system) defines ‘digital procedural standard’ as the technical specifications for business process models and data schemas which set out the electronic structure of the data exchanged through the e-CODEX access points. The business process model shall be developed, maintained and updated applying the Business Process Model and Notation (BPMN) or other industry-wide standards for business process modelling. The data schemas shall allow for interoperable data exchanges through e-CODEX. Therefore, for the purposes of the digitalisation of Directive 2014/41/EU, this Annex shall set out the technical specifications for: (a) business process models, (b) data schemas. 2. Technical specifications for the business process models under Directive 2014/41/EU The technical specifications for business process models shall be considered minimum specifications and shall set out the key aspects necessary for enabling electronic communication for the purposes of Directive 2014/41/EU through the decentralised IT system, and shall include both cross-border communication instances and, where Member States choose to utilise the decentralised IT system for that purpose, those between national actors (e.g. in case of a transmission or receipt through a Central Authority, where applicable). They shall be as follows: 2.1. European investigation order Issue and Transmit EIO Process model — Issue and Transmit an EIO (Annex A): the Issuing Authority issues an EIO and transmits it to the Executing Authority (where applicable, through the designated Central Authority); — Provide additional information: the Issuing Authority provides additional information to the Executing Authority (where applicable, through the designated Central Authority); — Change EIO (Annex A): the Issuing Authority replaces the original EIO with a modified EIO and transmits it to the Executing Authority (where applicable, through the designated Central Authority); — Issue and transmit supplementary EIO (Annex A): the Issuing Authority issues an EIO which supplements an earlier EIO and transmits it to the Executing Authority (where applicable, through the designated Central Authority); — Send a notification message: the Issuing Authority sends a notification about the legal remedies sought against the issuing of an EIO to the Executing Authority (where applicable, through the designated Central Authority); — Withdraw an EIO: the Issuing Authority informs the Executing Authority about withdrawing the EIO in whole (where applicable, through the designated Central Authority); — Request a status update: the Issuing Authority requests a status update about the evolution of the recognition and execution of an EIO from the Executing Authority (where applicable, through the designated Central Authority); — Send and receive any other communication needed in the context of an EIO to/from the Executing Authority or where applicable to/from the designated Central Authority. Receive and Execute EIO Process model — Receive an EIO and send confirmation of receipt (Annex B): Executing Authority receives the issued EIO from the Issuing Authority and sends confirmation of receipt (where applicable, through the designated Central Authority). In case of a forward of an EIO, this obligation applies both to the authority, which initially received the EIO, including the designated Central Authority, and to the authority to which the EIO was forwarded; — Forward an EIO and inform the Issuing Authority about the forward (Annex B): if the authority, which received the EIO, is not the competent one or is only partially competent, or if the EIO is received by the designated Central Authority (where applicable), the EIO is forwarded to the competent Executing Authority in the Executing State, and the authority, which forwards the EIO, informs the Issuing Authority about the forward (where applicable, through the designated Central Authority); — Return an EIO: where an EIO has not been issued by an Issuing Authority as specified under Article 2(c) of Directive 2014/41/EU, the Executing Authority returns the EIO to the Issuing Authority (where applicable, through the designated Central Authority); — Send a notification message: the Executing Authority notifies the Issuing Authority about a given situation under the following provisions of Directive 2014/41/EU: recital 22, Article 10(4) and (5), Article 12(5) and (6), Article 14(5), Article 15, Article 16(2), points (a), (b) and (c), Article 16(3), point (b), Article 19(2), Article 32(2) and 32(5) (where applicable, through the designated Central Authority); — Request additional information: Executing Authority requests additional information from the Issuing Authority (where applicable, through the designated Central Authority); — Inform about the progress of an EIO: the Executing Authority informs the Issuing Authority about the progress of the recognition and execution of the EIO (where applicable, through the designated Central Authority); — Send the Results of execution of an EIO: the Executing Authority sends the results of the execution of the EIO (either in whole or in part) to the Issuing Authority (where applicable, through the designated Central Authority); — Refuse an EIO: the Executing Authority informs the Issuing Authority about refusal of EIO (where applicable, through the designated Central Authority); — Terminate process upon withdrawal of an EIO by the Issuing Authority; — Send and receive any other communication needed in the context of an EIO to/from the Issuing Authority or, where applicable, to/from the designated Central Authority. Issue and Transmit Request for Transit Process model — Issue and Transmit a Request for Transit: the Transit Requesting Authority (an authority of the Issuing State competent to issue a Request for Transit) issues a Request for Transit and transmits it to the Transit Granting Authority (an authority of the Member State of Transit competent to grant transit); — Provide additional information: the Transit Requesting Authority provides additional information to the Transit Granting Authority; — Withdraw a Request for Transit: the Transit Requesting Authority informs the Transit Granting Authority about withdrawing the Request for Transit in whole; — Send and receive any other communication needed in the context of the Request for Transit to/from the Transit Granting Authority. Receive and Reply to Request for Transit Process model — Receive a Request for Transit: Transit Granting Authority receives a Request for Transit from the Transit Requesting Authority; — Forward a Request for Transit: if the authority, which received the Request for Transit, is not the competent one, it forwards the Request for Transit to the competent Transit Granting Authority; — Request additional information: Transit Granting Authority requests additional information from the Transit Requesting Authority; — Send a reply to the Request for Transit: Transit Granting Authority sends the reply to the Request for Transit (informing of its decision on whether transit is granted) to the Transit Requesting Authority; — Terminate process upon withdrawal of the Request for Transit by the Transit Requesting Authority; — Send and receive any other communication needed in the context of the Request for Transit to/from the Transit Requesting Authority. 2.2. Interception of Telecommunication Notification (ITN) Issue and Transmit ITN Process model — Issue and Transmit an ITN (Annex C): The Competent Authority of the Intercepting Member State issues a notification about the interception of telecommunication and transmits it to the Competent Authority of the Notified Member State; — Provide additional information: the Competent Authority of the Intercepting Member State provides additional information to the Competent Authority of the Notified Member State; — Change ITN (Annex C): the Competent Authority of the Intercepting Member State replaces the original ITN with a modified ITN and transmits it to the Competent Authority of the Notified Member State; — Withdraw an ITN: the Competent Authority of the Intercepting Member State informs the Competent Authority of the Notified Member State about withdrawing the ITN in whole; — Send and receive any other communication needed in the context of the ITN to/from the Competent Authority of the Notified Member State. Receive and Reply to ITN Process model — Receive an ITN: the Competent Authority of the notified Member State receives an ITN from the Competent Authority of the Intercepting Member State; — Forward an ITN: if the authority, which received the ITN is not the competent one, it forwards the ITN to the Competent Authority of the Notified Member State; — Request additional information: the Competent Authority of the notified Member State requests additional information from the Competent Authority of the intercepting Member State; — Send a notification message: the Competent Authority of the notified Member State sends a notification to the Competent Authority of the Intercepting Member State informing about a decision taken that the interception may not be carried out or shall be terminated, and where necessary that any material already intercepted while the subject of the interception was on its territory may not be used, or may only be used under conditions which it shall specify; — Terminate process upon withdrawal of the ITN by the Competent Authority of the Intercepting Member State; — Send and receive any other communication needed in the context of the ITN to/from the Competent Authority of the Intercepting Member State. 3. Technical specifications for data schemas The following paragraphs outline the provisions for the technical specifications that shall serve as a basis for developing XML Schema Definitions (XSDs) for the digitalisation of Directive 2014/41/EU. These specifications define the key components, and any other information in order to provide a comprehensive description for the production of these schemas. The description is intended to be generic allowing the produced XSDs to be modified and extended without requiring changes to these specifications. The specifications are provided for the statutory form, predefined message or free text message used in the exchanges under Directive 2014/41/EU. 3.1. General Considerations For all schemas to be provided, the following provisions shall apply: Versioning A version attribute shall be included to facilitate schema versioning management. This will allow to update the schema in future iterations as per the business requirements, indicating whether the new version is backward compatible when introducing new features or refinements. Schema Declaration and Metadata Where applicable, the schema shall make use of relevant standards or vocabularies, applied by e-CODEX to provide interoperability, which are necessary for the proper validation of the elements and types defined within this schema. This may include: — EU e-Justice Core Vocabulary — Aggregated Components — Unqualified Data Types — A code list for European Union Language Codes Also, where applicable, the schema may incorporate relevant ETSI standards to make use of their definitions. Annotations and Documentation Annotations: Each element in the schema shall typically be accompanied by annotations. These should provide human-readable information about the element, often defining its purpose or usage in a clear and concise manner. Usage and Adaptability Modular Structure: Each section shall be designed with specific functionality and may be reused or adapted independently. This should make the schema easy to customise for different use cases. Extensibility: The schema shall be designed to support the inclusion of new elements or attributes if additional information is needed in the future. This may be achieved by using optional elements and sequences that may be extended without breaking existing implementations. Adaptable Structure: The schema shall be designed with the purpose of allowing for the addition or modification of elements or data types as necessary. The form’s structure may accommodate changes in requirements without major redesigns. Optional Elements: Many elements within a form may be marked as optional, meaning they may be included or omitted based on specific circumstances. The schema shall be designed to support the collection of structured data for specific requests. Modifications The schema design shall emphasise flexibility, modularity, and ease of adaptation. The use of complex types and optional elements shall ensure that it may handle diverse scenarios while remaining easy to modify and extend. 3.2. Statutory Forms The technical specifications for the data schemas shall define a structured framework for representing the forms, as set out by Directive 2014/41/EU, in XML format. 3.3. Predefined messages Predefined messages are representations of exchanges established by Directive 2014/41/EU, but for which no specific form was provided in the legal act. Their types and number will be determined during the business and technical analysis. Their schemas shall be designed to define a structure of XML Schema Definitions (XSD) ensuring consistency, structure, and compliance with business needs. The outline of the key components of these schemas shall be the following: — The top-level element in this schema shall be named according to the specific message type being defined. — The necessary fields required for the specific message type shall be added and defined within this structure, ensuring proper representation of data elements. 3.4. Free text messages Free text messages are representations of exchanges that allow for unstructured or partially structured content, enabling flexibility while still adhering to regulatory and business requirements. This schema is designed to define the structure of XML Schema Definitions (XSD) for these messages, ensuring consistency and proper formatting. The outline of the key components of these schemas shall be the following: — The Top-level Section in this schema shall be named according to the specific free text message type being defined. — The schema shall define the necessary structure for the free text message while allowing for appropriate ordering of elements as required. — The necessary fields required for the specific free text message type shall be added and defined within this structure, ensuring proper representation of data elements.