Digital procedural standard for the digitalisation of Regulation (EC) No 861/2007
ANNEX IIISupplementary provisions
ANNEX III Digital procedural standard for the digitalisation of Regulation (EC) No 861/2007 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 Regulation (EC) No 861/2007, 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 Regulation (EC) 861/2007 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 Regulation (EC) 861/2007 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 forward to another competent court or authority). They shall be as follows: Request for a European Small Claim Process — Submit a claim – The claimant fills in and submits a claim form (Form A) to the Court; — The claim is outside the scope of the Regulation – The Court informs the claimant in case the claim is outside the scope of the Regulation; — Claimant withdraws the claim – The claimant communicates to the Court that the claim is withdrawn; — Claimant informs the Court that they do not withdraw the claim – the claimant informs the Court that they do not wish to withdraw the claim; — Request by the Court to complete and/or rectify the claim form – The Court request the claimant (Form B) to complete and/or rectify the claim form; — Court dismisses the claim –The Court can also dismiss the claim; — Payments – The parties and the Court communicate regarding the payment of fees; — Forward to competent Court – The Court forwards the claim to the competent Court. Processing European Small Claims Process — The Court serves the claim form on the defendant – The Court serves the claim form and Form C on the defendant; — The defendant submits a response to the claim – The defendant submits a response to the claim (Form C); — The defendant submits a counterclaim – The defendant submits a counterclaim (Form A); — The Court requires translation of a document – The Court requires translation of a document from the claimant or the defendant; — Oral hearing – The claimant and/or the defendant request an oral hearing which could be decided by the Court, or the Court decides to hold an oral hearing on its own motion; — Extension of a time limit – The claimant and/or the defendant request an extension of a time limit set by the Court and the Court takes a decision on the request; — Judgment by the Court – Judgment by the Court to the defendant and the claimant. Post-judgment — Appeal – In case an appeal against the judgment is possible under national law, the claimant or the defendant may file an appeal; — Review of the judgment – The defendant may request a review in exceptional cases and the Court decides on the request for review; — Request for certificate – The Claimant or the defendant request the certificate (Form D) from the Court. 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). 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 below are provided for the statutory forms, predefined messages or free text messages used in the exchanges under Regulation (EC) 861/2007. 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 — 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 Regulation (EC) 861/2007, in XML format. 3.3. Predefined messages Predefined messages are representations of exchanges established by the Regulation, 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 will be added and defined within this structure, ensuring proper representation of data elements.