Digital procedural standard for the digitalisation of Framework Decision 2002/584/JHA
ANNEX IVSupplementary provisions
ANNEX IV Digital procedural standard for the digitalisation of Framework Decision 2002/584/JHA 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 Framework Decision 2002/584/JHA, 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 Framework Decision 2002/584/JHA 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 Framework Decision 2002/584/JHA 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). To ensure compliance with Articles 9 and 10 of Framework Decision 2002/584/JHA, the workflows supporting the business process models described below shall account for the possibility of transmitting an EAW outside the decentralised IT system, including via the Schengen Information System (SIS). However, the actual communication process through such channels is out of scope of this Digital Procedural Standard. The technical specifications for business process models shall be as follows: Issue and Transmit EAW Process model The issuing judicial authority issues and sends an EAW to the competent executing judicial authority in the Member State where the requested person is (believed to be) located. Receive and Execute EAW Process model Upon receipt of the EAW, the executing judicial authority assesses the request and decides whether to surrender the requested person to the issuing State or to refuse. Surrender Requested Person Process model When the executing judicial authority decides to surrender the requested person they inform the issuing State authorities. This business process also addresses conditional surrender and postponement, as well as transit through the territory of another Member State, where applicable. Refuse to Surrender Requested Person Process model When an executing judicial authority decides to refuse to surrender the requested person they inform the issuing judicial authority. Withdraw EAW Process model If the issuing judicial authority decides to withdraw the EAW, they notify to that effect the executing judicial authority, where the requested person has been deprived of liberty. Withdrawal may take place after the EAW is issued and transmitted until the surrender is effected. Prosecution for Other Offences Process model If an issuing judicial authority intends to prosecute a requested person for other offences (cf. Article 27 of Framework Decision 2002/584/JHA), and provided there is no situation of presumed consent pursuant to Article 27(1) of Framework Decision 2002/584/JHA, the issuing judicial authority makes a request in the meaning of Article 27(4) of Framework Decision 2002/584/JHA. Surrender to a Third Member State Process model A third Member State may request the surrender of a person, who has been previously surrendered from one Member State to another. In such cases, the last executing State of the EAW must provide its consent. Extradition to a Third Country Process model In accordance with Article 28(4) a person surrendered on the basis of an EAW cannot be extradited to a third State without the consent of the authority of the Member State, which has surrendered the person. 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 Framework Decision 2002/584/JHA. 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 annexed to Framework Decision 2002/584/JHA, any predefined message, or free text messages used in exchanges under Framework Decision 2002/584/JHA. 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 shall 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 shall 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 shall 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: 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 Framework Decision 2002/584/JHA, in XML format. 3.3. Predefined messages Predefined messages are representations of exchanges established by Framework Decision 2002/584/JHA, 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 (XSDs) 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.