Open Call for Tender VT/2008/019. Informatics services and products in the context of the. Technical Specifications

Transcription

1 Open Call for Tender VT/2008/019 Informatics services and products in the context of the EESSI (Electronic Exchange of Social Security Information) project Technical Specifications Call for Tender VT/2008/019: Technical Specifications 1 of 101

2 Invitation to tender No VT/2008/019 Note to tenderers This call for tender is made up of the Administrative and the Technical Specifications and their Annexes. The reader is hereby made aware that the Administrative and Technical Specifications complement each other and tenderers are strongly recommended not to read the Technical Specifications in isolation of the Administrative Specifications or vice versa. The Technical Specifications have five annexes: Annex T1: EESSI flows Annex T2: EESSI data Annex T3: Social Security indicative exchange metrics Annex T4: Guidelines for installing applications at the Commission's Data Centre Annex T5: Directory attributes Call for Tender VT/2008/019: Administrative Specifications Page 2 of 101

3 Table of Content 1. Introduction General presentation of the EESSI architecture The EESSI Architecture The Coordination Node (CN) and the Access Point (AP) The Coordination Node (CN) The Access Point (AP) The Reference Implementation (RI) The Directory Service Business Protocols and the Structured Electronic Data (SED) The resources The objective Requirements Analysis and Design SED Development and Business flows Introduction Flow Requirements Required features in the flow framework The Coordination Node The Message Relay (MR) The Information Repository Monitoring and logging in the CN Statistics Operational Aspects Access management Console The Reference Implementation Infrastructure to host the RI Web Interface for the clerk The interface with national application (NPAP) Messaging EMS input and output queues Queue/web interface routing SED validation Encryption/decryption File packaging Message Transport Agent Monitoring and logging in the RI Statistics Interface for manual routing Transport and routing The conversions Security Interface for the data mapping and conversion Plugins Remote update facilities Console The Directory Service Hosting Call for Tender VT/2008/019: Administrative Specifications Page 3 of 101

4 Managing identity of EESSI participants Information stored in the Directory Storing the attributes of the institutions in the Directory Service Accessing the Directory data Responsibility of maintenance Versioning and historical records Security and accountability Provisioning of search applications Directory architecture The addressing scheme issue The replication mechanism and protocols The Security in EESSI The needs Envisaged security Data Exchange diagram General guidelines for solutions SED Message security Access control The Gateway service Scalability and failover The EESSI system's minimum requirements Framework for a solution Introduction The Coordination Node Application Server Selection Web Service Stack Choice Directory Server Choice Application update client and server Messaging Protocol Specification SED and Business Protocol Design Common Conversion Services Development Messaging Service Integration Directory Service Development and Integration Web UI Development SED Form Engine and Workflow Selection Help Desk Setup Packaging and Deployment Scalability and failover Orientations for a solution Deployment in a very heterogeneous environment Handover Tests (FAT and SAT) Factory Acceptance Test - FAT Site Acceptance Test SAT Performance Tests of the Message Relay at the Coordination Node Testing application Live Tests Tests for the EESSI Master Directory Tests on the Reference Implementation (RI) Web interface for clerks 80 Call for Tender VT/2008/019: Administrative Specifications Page 4 of 101

5 Tests on the Reference Implementation (RI) national connectivity (NPAP tests) Test on the Business Flows procedures Tests on the Information Repository Nationally developed IPAP tests Test and Production System Stress tests Security Tests Deployment of the EESSI components Migration of the CLD data into the Directory System Uploading of the national data into the Directory System Population of the Directory System Deployment of the Co-ordination Node (CN) and RI Protocol Design and Document Introduction Messaging Service: Fundamentals Point-to-point and publish/subscribe Broadcast Routing Support for large messages Messaging Service: Reliable Messaging Guaranteed message delivery Sequencing of messages Network error handling Message processing loads alerts Security Messaging Service: Specifications and Development Messaging Protocol: Patterns Business Protocol: Importance of Flexibility Business Protocol: Guiding Principles for SED Business Protocol: Borrowing Concepts from Software Engineering Business Protocol: Workshops LDAP Protocol Documentation Developer Documentation Coordination Node API Reference Implementation API End User Documentation Trainer and support documentation Administrator Documentation Training and Help Desk Training Help Desk EU Standards Workplace and infrastructure Model of Monthly Progress Report List of Annexes Call for Tender VT/2008/019: Administrative Specifications Page 5 of 101

6 List of Figures Figure 1: EESSI High-level Architecture... 9 Figure 2: s-testa and EESSI Figure 3: Access point functionality Figure 4: Access point SED routing Figure 5: Interconnection of the national Access Points and stesta Figure 6: General presentation of the EESSI Directory structure Figure 7 National and International Domains in the Access Point Figure 8: Reference Implementation architecture Figure 9: Access point national part, web-interface and statistics Figure 10: EMS architecture Figure 11 Separation of responsibility between the Reference Implementation and National developments within Access Points Figure 12: Example of Web Interface for the Directory Service Figure 13: Hierarchical addressing scheme Figure 14 Data Exchange Diagram Figure 15 : Gateway services of EESSI Figure 16 : Reference implementation high-level view Figure 17: Web services stack Figure 18: Example of a protocol Figure 19 : Message relay through the Coordination Node Figure 20 : Reference implementation overview Figure 21. Testing applications Figure 22 : mandatory use of the Coordination Node Call for Tender VT/2008/019: Administrative Specifications Page 6 of 101

7 1. Introduction This document specifies the technical requirements for the Call For Tender. Tenderers are to specify their plans for analysing, designing, building, installing and documenting the EESSI system, with a view to handing it over to the Commission. EESSI must be delivered as a whole project but it may help the reader to understand the following sections because EESSI development and implementation consists of four major parts, each being run under different time constraints, as indicated in sections 7 and 8 of the Administrative Specifications. Coordination Node and Reference Implementation: They offer a number of services, mostly the messaging service which is made of portions of the Coordination Node, the Reference Implementation and, in some countries, implementations by the Member States. The messaging service will handle the bulk of the traffic on EESSI, which makes it a key component. Since many Member States will access the EESSI system via their own national networks and applications, a crucial part of the EESSI system is to be developed by them, and is called the "National Part of the Access Point" (see 2.2.2). Therefore, although this portion is the central part of EESSI, its operation is delayed towards the handover period, to ensure coherent timing with national developments. Other services include the Web interface for clerks (see ), various administration management tools (e.g. the console, see ), the repository service that holds a copy of all information pertinent to EESSI, local copies of the Directory for faster access and security, etc. See the detailed specifications in 3 for the normative list. SED message development and business flows: this is parallel to the development of the Messaging Service. Whereas the messaging service provides the technical exchange conduit, the SED is the message that is being exchanged. Directory services (DS): including the public access to the directory for European citizens: on one hand the purpose of the DS is to facilitate the routing of the SED messages and on the other hand this ties into the legislation and must be operational prior to the application of the legislation 1. Protocol design and document: it describes the inner working of mainly - the messaging service as well as the interfaces between the Member States applications and the messaging service. It has to be provided early enough in order to give Member States sufficient time to implement it. In addition, please note that the Reference Implementation will include all the network aspects but also a Web Interface for clerks, not to be confused with the administrator console. It appears that few Member State will be able to complete their national part of the Access Point in time for the project start. Furthermore some exchanges are very infrequent in certain countries. The web interface for clerks is therefore intended to address this by providing a 1 The Directory has to be ready well in advance of the implementation of Regulation 883/04; in the Schedule in the Administrative Specifications, the full Directory must be completed by month 12 of the contract term. Call for Tender VT/2008/019: Administrative Specifications Page 7 of 101

8 minimal level of compliance and a Member State can always rely on its availability to jumpstart their efforts. The web interface must be available from the day EESSI goes in production. Again, and for clarity, the contractor must deliver EESSI as a whole and all phases are equally important to achieve this goal. Moreover the technical specifications aim at giving a detailed and concrete description of what is expected from the tenderer and the tenderer who is awarded the contract. In addition, they aim to provide a description of the business that the EESSI system is to accompany. Tenderers may interpret the requirements and propose changes in the interest of the effective and efficient exchange of information. However, variations on the specifications below will be accepted only if the requirements are respected in principle if not in the letter - and there are important justified advantages in the tenderer's proposals. This should be seen in the context of the RUP or RUP-like (any other iterative software development process) framework, which should be implemented to carry out EESSI, as indicated in the Administrative Specifications. 2. General presentation of the EESSI architecture The main purpose of the EESSI system is to allow the exchange of information (SED messages, as mentioned above) between Competent Institutions (CI) in different countries. CI's will not contact each other directly. Rather, their SED messages will go to their national Access Point, from which they will be forwarded to the Coordination Node, from which they will be forwarded to the Access Point in the country of the destination CI, from which they will be forwarded to the destination CI The EESSI Architecture One major output of the feasibility study on EESSI is the architecture of the International Network. As illustrated in Figure 1 the high-level architecture of EESSI International Network is composed of (i) the EESSI network backbone, (ii) the coordination node in its entirety and (iii) international parts of the access points. Call for Tender VT/2008/019: Administrative Specifications Page 8 of 101

9 National Network National Network National Network Member State 2 Member State 1 EESSI Backbone Network EESSI International Domain National Network Member State 3 Member State 4 National Network National Network Coordination node Access point EESSI international part of access point EESSI national part of access point Figure 1: EESSI High-level Architecture The EESSI Backbone As regards the EESSI backbone, Member States unanimously supported the following principle: Use of a closed network as the EESSI backbone network On adopting this principle, Member States also adopted s-testa as the EESSI backbone data network and a network topology as illustrated in Figure 2. Call for Tender VT/2008/019: Administrative Specifications Page 9 of 101

10 CI2 CI1 CI3 CI4 CI5 CI2 CI3 National Sectorial Network 1 National Sectorial Network 2 CI6 CI1 National Sectorial Network CI4 AP1 AP2 AP1 MS 4 National Network connected to s-testa LDCP LDCP MS 3 National Network connected to s-testa MS 1 National Network connected to s-testa LDCP s-testa s-testa Security Accreditation Domain LDCP MS 2 National Network connected to s-testa AP1 AP2 AP1 AP3 National Sectorial Network 1 National Sectorial Network 2 National Sectorial Network 1 AP2 National Sectorial Network 2 National Sectorial Network 3 CI1 CI2 CI3 CI4 CI5 CI6 CI1 CI2 CI3 CI4 CI5 CI6 CI7 CI8 CI9 APn Access point n CIm Competent Institution m Figure 2: s-testa and EESSI 2.2. The Coordination Node (CN) and the Access Point (AP) The Coordination Node (CN) The Coordination node (CN) is an application that will serve three main purposes. 1. A major purpose of the CN is that of hosting the Master Directory. For details about this tenderers should refer to the relevant sections, namely 2.4 and The second and most important function of the CN is the relay of messages from and to Access Points. 3. The Coordination Node will also host information such as information on XML schema in addition to the Master Directory. As can be seen, its role is multi-faceted but, generally speaking, it is the hub through which all exchanges (be they messages, addressing information or specifications) take place. Call for Tender VT/2008/019: Administrative Specifications Page 10 of 101

11 For the purposes of organising the functional specifications, we have grouped them in six distinct services, which are outlined below: Directory: It concerns the hosting of the EESSI Directory (see 2.4 of this document); this includes the Master and Public versions Messaging: The Coordination Node assumes the role of a messaging hub between access points Gateway: It provides generic gateway services to services offered by Access Points, acting as a proxy Monitoring and logging: It monitors the status of the Node and logs all activity Security: It is a horizontal service dealing with all security aspects Information Repository: It contains general information on the EESSI system, including flow and message definitions The Directory and messaging are complex sections and are dealt with in separate sections. All the other functionalities above are dealt with in detail in The Access Point (AP) The background to this is that one of the challenges of building a pan-european network for social security is the extreme diversity of situations in the Member States. Some Member States have only a handful of Competent Institutions while others have 1000s of them. This diversity will persist throughout the lifetime of EESSI. As proposed by the feasibility study, Member States have accepted that the international data exchange is exclusively performed by a small number of Access Points. The Access Point is a national hub that hides the particularities of the national situation. For those Member States with several thousand Competent Institutions, it also brings the number of connections down to a manageable number at the international level. Member States will connect the Access Points to their Competent Institutions under their own responsibility. An Access Point consists of two logical parts, namely the International Part (IPAP) which is part of the EESSI international domain and a National Part (NPAP), which is responsible for the communication with Competent Institutions. Both are installed on Member State premises. This is illustrated in Figure 1 The Access Point is a unique and clearly defined interface between the EESSI European domain and the national domain and all electronic data exchanges are routed through the Access Points. The Access Point is defined as being the entity providing the functions of electronic contact point. This entails sending and receiving of SEDs, both from counterparty foreign Access Points and national Competent Institutions 2. All Access Points implement automatic routing, in which an inbound (international) SED (i.e. sent by a counterparty access point of another MS) is forwarded automatically to the intended recipient Competent Institution, provided that the SED complies with the EESSI standards and the recipient is clearly defined, 2 The communication between AP and the national Competent Institutions is for the National Part of the Access Points. This is to be built by the Member States themselves and out of the scope of this project. Call for Tender VT/2008/019: Administrative Specifications Page 11 of 101

12 intelligent routing of inbound SED on an optional basis. The optional intelligent routing function is activated when automatic routing is not feasible and may comprise the following two optional components: o Software-assisted routing, whereby a software application attempts to identify the target recipient Competent Institutions by analysing several parameters (here called attributes ) of the SED 3. An example of softwareassisted routing may be the implementation of a rule-based engine. o Human-assisted routing, whereby a person with sufficient experience in social security in a Member State will identify the recipient Competent Institution. There will be at least one AP per Member State. In addition, the Commission may have an Access Point in its Paymaster's Office for Unemployment benefits and will install a few Reference Implementations (which implement the International part of an AP, see 2.3 of this document) for testing and trouble-shooting purposes. Access Points have on-line connections with the s-testa Local Domain Connection Point LDCP through a national network. Figure 5 illustrates in more detail the high-level national EESSI network architecture and s-testa. Both the (i) national networks through which Access Points have on-line connection with the s- TESTA LDCP and (ii) the sectoral (e.g. pensions, health-care) networks through which national Competent Institutions are connected with their Access Points are, in principle, Member-State-specific. As such, their architecture and technical features are beyond the scope of the present project. The only EESSI requirement is that Access Points have on-line network connections with the s-testa LDCP. Electronic contract point CI MS Y1 Access Point EESSI International Network International traffic National traffic National network CI CI MS Y2 Access Point Intelligent routing (optional) Access point CI Inbound traffic Outbound traffic Competent Institution Structured Electronic Document - SED 3 These are typically social security sector, industry, region of competence but can be more specific in some countries (see Annexe T5) Call for Tender VT/2008/019: Administrative Specifications Page 12 of 101

13 Figure 3: Access point functionality Member States have full discretion as to whether they provide in their own Access Points the functionality of intelligent routing for inbound SED, and whether this entails (i) softwareassisted routing, (ii) human assisted routing, or (iii) both. Figure 4 illustrates the routing algorithm that may be implemented at the level of the Access Point. Receive inbound SED from access points Is recipient adequately defined? Yes Route SED to Competent Institution No Return SED to sender access point No Intelligent routing implemented? Yes Human intervention and/or software processing Return SED to sender access point No Recipient identified? Yes Structured Electronic Document - SED Figure 4: Access Point SED routing Since the EESSI International Network will be based on stesta and Competent Institutions will exchange information exclusively via Access Points, the Access Points as illustrated in Figure 5 will have on-line connections with the stesta Local Domain Connection Point LDCP through their national networks (national TESTA network) S-TESTA LDCP Sectorial access point (e.g. Healthcare) National Network Sectorial access point (e.g. Pensions) National sectorial network National sectorial network Competent Institution Competent Institution Competent Institution Competent Institution Competent Institution Figure 5: Interconnection of the national Access Points and stesta Call for Tender VT/2008/019: Administrative Specifications Page 13 of 101

14 2.3. The Reference Implementation (RI) A standard International Part of the Access Point (IPAP) will be developed by the contractor within the current EESSI project; this is called Reference Implementation (RI). The Commission will offer the RI, free of charge, to Member States that intend to use it. Member States, however, have reserved the right not to use the standard RI and build IPAPs themselves. While we expect that at least a large majority of Member States will adopt the RI, it is possible that some countries will build their own IPAP using the specifications of the RI, as noted below (see 4). After the end of the contract, the RI will be maintained by the Commission. Countries that develop their own IPAPs must be provided with clear specifications as regards the connectivity to the CN. In any case, all countries must build the National Part of the Access Points (NPAP) unless they decide to rely solely on the web interface for clerks. Given that the Member States have the freedom to deploy their own version of the IPAP, the contractor must (1) document properly the messaging protocol and (2) base it on public standards and protocols The Directory Service The Directory Service consists of the EESSI Master Directory and Public Directory; the latter is a copy of the Master Directory. There will be copies of the Master Directory in the Access Points as well. The EESSI Directory will be the authoritative repository of the list of Competent Institutions. It will include information on both business (e.g. competence, functions, types of benefits covered, personal and geographical coverage) and technical/routing matters (e.g. computer address of the Access Points, Competent institutions, etc.). The Directory Service is one of the cornerstones of EESSI; it is the core of the routing mechanism of EESSI. Its purpose is to provide the clerks, the national application and the European citizens with an electronic facility for determining where the information should be sent or which Institution should be contacted, on any given occasion. Through a Web-based interface European clerks or citizens will have the possibility to query the EESSI Public Directory by providing as much information as possible on the competence of the Institutions they are looking for (e.g. the type of benefit, the personal and geographical coverage, etc). The Directory Service, on the basis on the query information provided, will provide either result information as a single matching institution or a list of several institutions, all matching the query information. In the current phase of the project, a similar system is already operational but limited to the Health Insurance Card (EHIC); it is called the Code List Database (CLD 4 ). It is a Web Application with a database where some information related to the Competent Institutions of the health-care sector are stored and made available to the European clerks and the general public through the Internet. In addition, the EUlisses 5 portal contains a Competent Institution search mechanism that is country-specific, limited to the pensions sector. While these two search facilities (CLD and EUlisses) provide useful examples, the search facility requirement for the Directory is expected to have extended functionalities, as described in Call for Tender VT/2008/019: Administrative Specifications Page 14 of 101

15 For the purpose of routing in EESSI, it has been decided to replace the CLD by a full Directory Service 6 which is to cover all sectors of social security. On the technical side, it should comply with major directory standards, such as LDAP. As a consequence, EESSI should offer the service of a directory mechanism to store three types of information: 1. Routing information: reference and operational data required for the routing of the SED to the final Competent institution 2. Security information: certificates and keys 3. Administrative information The Coordination Node will be submitted to access control. This will apply, i.a., to the Master Directory to make sure that only authorized users can modify the information and that they are limited to editing information they are responsible of. This is standard procedure. Because the Master Directory will be hosted on stesta and stesta is not accessible from the Internet, it has been decided to replicate the Directory in all the Access Points (for Member State purposes) and to make an additional copy available from the Commission's Data Centre to the public at large on the Internet through a web-based interface (see description below, i.e. Figure 6). As the picture below shows, copies of the Master Directory should be distributed regularly and automatically to all Access Points for national access from the Competent Institutions and/or national application and to the Data Centre for the general public access. There is therefore a need for a replication mechanism. Figure 6: General presentation of the EESSI Directory structure 6 Technically, EUlisses will not be replaced; it will continue to exists after the Directory is activated and its contents will not be transferred automatically. However, the Directory will also cover the pensions sector and it is expected that all institutions listed in EUlisses will also be listed in the Directory. Call for Tender VT/2008/019: Administrative Specifications Page 15 of 101

16 A major part of the EESSI directory will be updated by the Member States themselves, at least as regards the information related to their own national institutions through a dedicated interface provided (developed or off-the-shelf) for that purpose and available in the Access Points. This interface must be specified and developed by the contractor and should allow bulk upload of information as well as the possibility to edit/modify/delete entries individually. Other entries, such as the Access Points will be directly updated by central administrators via the Coordination Node. A part of the information stored in the Directory should also be made accessible to the general public through an Internet application that should also be specified and developed by the contractor. Once the Directory will be set up, tested and operational, the information contained in the old CLD 7 will have to be transferred into the new EESSI Directory. Information on institutions for other social security sectors, including pensions, will be uploaded separately Business Protocols and the Structured Electronic Data (SED) The main EESSI business will be that of exchanging information in the form of structured Electronic Documents (SED) within flows following pre-determined schemes 8. Each flow will complete a claim for benefits or right assessment 9. Each flow will consist of one or several messages that are exchanged between national administrations (CIs). Each message will be codified as a SED, in XML, and will be one of several pre-specified types. Messages contain data items which themselves are pre-specified. As a consequence, flows and message contents will follow pre-determined structures. One part of the EESSI architecture rests on the definition of these structures. It must be borne in mind that flows, messages and data items are not static and will be intermittently updated, as and when the Sectoral Committees require changes. This will require versioning The resources As resources to build the start-up flow and SED structures, the contractor will be provided with flow, SED and data definitions. These are established by expert groups, consisting of national administrators and technicians, who draw up the EESSI flows. At call-for-tender time, these flows and messages will be described in a summary, simply and in diagrammatic fashion. The purpose of this description is to give tenderers an idea of the size, variation and complexity of the flows and messages. Tenderers will find such description in annexes T1 and T2. In addition tenderers can find an example of the information produced via the UML tool relating to the sickness sector in Once the call for tender is launched, the Commission will continue to work on the flows so that, at contract signing time, the contractor will be able to build on UML 10 versions of the flows and messages for some sectors 11. Please also consider the Contractor's duty in this regard as outlined in See 8 All this emanates from Regulation 883/2004 and its implementing Regulation. 9 In addition, there will be simpler flows, for instance just to ask for information. 10 The Commission uses Poseidon as UML tool. 11 The work on the outstanding sectors will be completed during the contract term and the successful tenderer will be involved (see 4.9) Call for Tender VT/2008/019: Administrative Specifications Page 16 of 101

17 Not all flows, messages or data will be provided at contract start time. A few additional ones will be specified later as the national expert working groups complete their work based on the legislative text agreed in the Council The objective The objective here is to build a "flow model directory", consisting of message and flow definitions at CN level. This should allow the web interface for the clerks in the RIs in the APs, and national systems, to tap into the information encompassing the data in the message for a variety of usages, including Informing the web interface for the clerks about SED formats 12. For instance, when initiating a flow (to start and process a claim, for instance), a clerk should be able to browse through flow types and launch the one that suits their claim at hand. This web interface should be able to prompt the clerk with a first message to be filled and then sent, thus initiating a flow (typically, a claim). Likewise for responses, the web interface for the clerks should propose the expected response message, with data to be filled-in by the clerk. Informing national applications that Member States can build on the basis of their data bases to initiate and respond to messages automatically. Maintain a central reference on available flows and messages. Whilst the majority of all flows and messages will have been defined by the time the contract starts, there may be a small amount outstanding. In addition, it is also possible that the Commission and the Member States will introduce new flows, or modify existing ones. This may or may not happen during the duration of the EESSI project. But inevitably, because of the evolution or changes in national and European legislation, it will, for sure, happen once the contract has ended. Therefore the contractor shall provide a tool(s) 13 for implementing new or modifying existing flows, SEDs and data definitions. This tool should enable the Commission to modify the flow base. The contractor may wish to use the current provided flows as examples; these give an idea of the range of flow types. Tenderers are required to describe how they plan to provide such a tool(s) and what will be the main functionalities of this tool(s). There should also be a hierarchical organisation of messages, flows and data, or in any case a classification that would enable clerks to search for the needed ones. In fact, there will be hundreds of flows, with hundreds of message types, containing thousands of data items, all connected among themselves, as seen in annexe T1 and T2, which lists the business flows and their accompanying data. In addition, the flow model directory should allow for language versions. While the contractors will only be required to implement the pre-defined flows in English, they should provide for the facility to upload other language versions. This applies to the data definitions, the message titles and explanatory notes as well as the flow definitions. Furthermore, some of the data items that are defined at European level will not find single counterparts in national databases. Some data conversion may be necessary, although this should be implemented at IPAP/NPAP level. 12 This interface id foreseen in the RI, as required below (see ). Countries that do not make use of the RI will probably still tap into this source of information on the business flows. 13 Please note that in of this document, this tool(s) is referred to as being the "SED and business flows tools". Call for Tender VT/2008/019: Administrative Specifications Page 17 of 101

18 More precise requirements are below (see 3.1.1) 3. Requirements The chapter above should have given you an overview of the EESSI system. Hereafter you will find the requirements for the components summarily described above. A fundamental element of the EESSI architecture is that electronic exchanges between Access Points will take place using Web Services and more specifically using the following Web Services standards: SOAP 1.2 MTOM WS-Addressing WS-ReliableMessaging WS-Security WS-Eventing (Optional) More details are given in Section Application Server Choice 3.1. Analysis and Design The first task of the contractor in the EESSI project will be to further detail the functional specifications that have surfaced from the feasibility study launched by the Commission on EESSI. All the Functional Specifications (FS) have been accepted and approved by the Member Sates through the various institutional fora (Task Force, Administrative Commission, Technical Commission, etc.). These Functional Specifications are the foundations of the EESSI project and must be used as such as the framework of the project. The reader will find the Functional Specifications within the text below and labelled "FS-xx", xx being a number between 1 and SED Development and Business flows Introduction As regards the EESSI data, message and flow definitions, it is felt that a central location should hold them as a reference; hence the Coordination Node should act as a repository for data, flows and messages. In the current exchange, information travels between Institutions in the form of E-forms, i.e. questionnaires consisting of pre-specified fields to be filled in. Bear in mind that one of the main tasks of the contractor will be to implement the XML SED, as specified above (see 2.5). It can be expected that some XML SEDs can be tailored to specific situations, most likely for a specific benefit, a specific step within the claim, a specific sending country and a specific receiving country. Therefore, the repository should be organised in sections, accessible via an Access Control List, which means that the Commission and the Member States can upload information where Call for Tender VT/2008/019: Administrative Specifications Page 18 of 101

19 they have the appropriate rights 14. During the term of the contract, the contractor must carry out the bulk upload of information into the repository. Because SED syntax could change in the future, this service of the CN should be accompanied by editors that enable the creation, deletion, editing and versioning of standard SEDs (see the section below). The data dictionary is important and it is the basis for constituting the standard SED models. In addition, because of the multi-lingual environment, the dictionary should be coupled with a language version system allowing countries to retrieve dictionary sections and terms with their own (and/or other) language versions. While, as specified below, the contractor will not be responsible for providing or editing any other version than English, they should build the dictionary in a way that allows uploading of all community languages and managing language versions rationally Flow Requirements The general need as regards the business flows is described in 2.5. You will find specific requirements in this section. In a nutshell, what is required is a repository of data, message and flow definitions that allows direct editing as well as bulk uploads of content browsing queries, with a view to o retrieving a suitable flow, on the basis of description about a claim (or other information exchange need) o retrieving a message, depending on a flow and a phase within the flow o retrieving a data item definition, within a message o managing the above, i.e., checking for duplications, re-use, group into structures or relations, etc. download individual data items, message or flow models, in a form that allows the RI or national applications to help clerks or automated systems to build and send messages. The purpose of such a system is to enable local systems and procedures to draw on an agreed and common protocol. Such a system/application would have to comply with a series of requirements, hereafter. More technical specifications can be found in and Required features in the flow framework The first requirement concerns multilingualism. It must be possible for Member States to add (edit, upload) versions in their own languages of definitions of data items, message and flow descriptions. It must also be possible for the RI and Member State applications to query for a specific language version of names, titles and definitions, if these exist (if they do not, a standard language, such as English, should be offered). 14 It is expected that this work will be carried out mainly by the Commission. Member States (clerks in the Access Points) may be allowed to input some country-specific information, typically language versions). Call for Tender VT/2008/019: Administrative Specifications Page 19 of 101

20 The second requirement concerns access control management. As described above, different people need to carry out different actions. This should be managed by an access control system, which could well be the same that applies to the rest of the EESSI system (e.g. the Directory). It is likely that this part of the system will be managed and accessed by the same actors as the rest of EESSI (i.e., the Commission at central level and the AP at national level, mainly as regards language versions). The flows, message and data should support versioning. It is quite possible that the Commission will need to apply changes in the future and it might be necessary to get to know which version of a data item, message or flow was applicable at a certain date in the past. SEDs must consist of envelopes and content. In principle, the envelope should be the same for all message types; on the contrary, message types should be characterised by their contents. As is usual with most messaging systems, each SED will bear an SED identifying number. This should be part of the envelope and the system should ensure that the SED number identifies a message unequivocally. Other envelope items are suggested in annexe T2; the envelope must be defined jointly with the Commission. SED must allow enclosures. These could be of any type, including images. As regards where the flow, message, models and data schemes should be located, you will find FS-78 below that suggests that these be located in the Information Repository in the CN. This solution has been formally approved by the committees. Nevertheless, the contractor is free to separate the information repository from the models and have two different applications manage them. On this, tenderers are requested to give suggestions and, if possible, even final choices The Coordination Node The Message Relay (MR) The Coordination Node acts as a messaging hub. More specifically, consider two access points, AP1 and AP2. AP1 sends a message to the CN, which stores it temporarily in a message hold area. CN then sends the message to AP2 (receiving and sending should be practically simultaneous as the message body is not analysed by the CN). The functional specifications of the coordination node messaging service are very similar to those of the Access Points (see ). In the interests of brevity, we will not repeat them in this section. The FS-72 below was further modified by a decision that the CN act as a hub, there fore the "may" below should be interpreted as "shall". L2:FS-72 The coordination node may provide the same messaging services as those provided by the access points The Information Repository The Coordination Node will provide an information repository in which EESSI documents, reference material and other useful documentation will be stored. The information would be for the social security administrators since there is already an established portal containing Call for Tender VT/2008/019: Administrative Specifications Page 20 of 101

21 information on social security to serve the wider public (the EUlisses 15 portal). Depending on the context, all documents to be placed in the Information Repository will be on agreement of the Administrative or Technical Commission. Such documents will include the UML models (and derivates such as XML schemas of SEDs, WSDL of flows, in the tool envisaged in 3.1.1), an EESSI data dictionary, the Regulations on which EESSI is based (e.g. Regulation 883/2004 and its Implementation Regulation) and Decisions of the Administrative Commission. Practical reference information material that may be of use generally may also be placed, e.g. lessons-learnt in a particular Member State from the implementation of the electronic exchanges in a particular sector. The Information Repository, like a library, will itself not be involved in the actual EESSI information exchanges. Its role will be supportive only. Access to the EESSI information repository will be provided by a user interface. L1:FS-78 The coordination node shall provide and host information repository functionality for (i) data dictionary, (ii) EESSI XML schemas, (iii) Regulations, (iv) reference material assisting Member States in carrying out their tasks. Access to the repository will be performed via a portal interface. The CN should also support the EESSI system management. This implies that information on system status, help and e-learning resources, support pages should be hosted in its information repository, as follows: 1. information repository on the functioning of EESSI itself, outlining, inter alia, national implementation status, flow capacity load, AP availability and upgrade schedules ; this can be a web page or a publish-subscribe service (RSS); 2. an overview, possibly with deployment function 16, of the AP application version deployment; this could also be separated from the main documents; 3. How-to's, e-learning, EESSI management and support contact points; 4. Support for software development: mailing list/forum, bug tracker, file repository and the other support typical in these projects (examples would be SourceForge, trac, and similar support centers). Tenderers are free to suggest a different structure for the services above, in particular if standard applications address the needs above in other ways. What is important is that the needs expressed above are met Monitoring and logging in the CN Generally speaking, the CN has to provide the same monitoring and logging functionalities that the AP has to provide. You will find the latter in below. In addition, the CN must provide the following: 15 See This is limited to the pensions sector for the moment. It is envisaged to extend it to all other social security sectors. 16 The RI deployment structure should be dealt with separately. It could be made part of the CN if the tenderers feels that this is a suitable solution. Call for Tender VT/2008/019: Administrative Specifications Page 21 of 101

22 L2:FS-73 The coordination node will log activities in a manner enabling an audit trail, In addition, it will be important for some purposes that the status of the EESSI system be monitored. It is important that AP have access to this information in real time. L2:FS-74 The coordination node will collect metrics in real-time (performance counters) for a variety of parameters (e.g. data transfer rate, message transfer rate, bandwidth utilisation etc.), such that the status of the services be quantitatively established. L2:FS-75 If the coordination node provides messaging services, then those shall be logged, both for incoming and outgoing messages 17. The CN will handle message transport issues, including support for CI clerks. For this purpose, the CN will need monitoring tools to track messages and problems. Tenderers are requested to indicate which monitoring features will be available with their proposed architecture. At a minimum, the contractor is to provide the usual monitoring facilities to 1. trace the source of any problems and errors and 2. generate automatic alerts on malfunctioning or other abnormal situations. For example, the following parameters are known to be useful (but more parameters will probably need to be monitored): time while system is up (availability); connection attempts: their status, duration, the message ID, the message status in the queues and times in queues, whether it s inbound or outbound connections and the address of the counterparty system. In case of error, the error message; Routing decisions; Queue sizes, in number of messages and bytes; Response time of the different nodes; Any congestion problem or other failure with the time stamp and message ID; The fields in the message envelopes. By definition, since it is a tool to identify problems, the monitoring must be robust and use all the best practices to resist data corruption, even in the case of a software failure. At the same time, since it is only really useful in case of problems, the logging should not impose too high a burden on the production environment. The output of monitoring and logging must be exportable in several formats, including either CSV or XML (or both). Logs must record different levels of details depending on the nature of the operations. For example, in a test environment, it may be desirable to enable more detailed logs that will record much more information per transaction, leading to volumes of logs that may not be 17 This was drafted before the decision was taken to have all messages go through the CN. The starting "if" should now read "since". Call for Tender VT/2008/019: Administrative Specifications Page 22 of 101

23 sustainable in production. Conversely, in production, it must be possible to turn off certain level of details in the logging or allow log-less events. Regardless of the level of details chosen, a minimal set of information must be recorded that enable tracing a message from the sending mailbox in the originating IPAP to the recipient mailbox in the receiving IPAP. The minimal set must enable tracing a message and either guarantee that it is properly delivered to the NPAP or indicate the source of the failure. The contractor must provide an interface to query on any parameter defined above. Queries need not be in real-time (the use of log files, as opposed to a database, is acceptable). Functionally, the interface must support the problem tracing that are typical of a production environment, including but not limited to the following: Given the message identification on an IPAP, find where the message currently is and, if it has been blocked by an error, provide enough information to identify the problem. If a node in the network is causing delays, retrieve aggregate information to help pinpoint the nature of the delay. Monitor the proper functioning and the performance of a node. Alert of bottlenecks in formation to help take proactive measures. Monitor the growth of traffic, over longer periods of time, particularly in relation with the resources available to assist in predicting system upgrades. Obviously the natures of the delays are many: network failure, human error, hardware malfunctioning, network congestion but also bugs in EESSI. So the log must be precise enough to trace predictable and unpredictable problems. The querying interface must be flexible to assist the administrators with problem identification. For example, a first query may be broad and return only aggregate data and be followed by more precise queries that will pinpoint the problem. The contractor should note that there will be no data protection issue since the information above (including that on the message envelope) does not include personal data. Obviously for the Coordination Node to offer the global view on the EESSI system that is required to monitor its operations, the Access Point must include reporting mechanisms. The contractor is free to propose the most efficient reporting mechanism, either by offering online queries on the status of the Access Point or by sending copies of the logs to the Coordination Node. The central EESSI system administrator must be given the option to control how long the logging data is kept, make new log files periodically, or limit the total size of the log. In addition to the tools to investigate malfunctioning, an alert mechanism must automatically "take the pulse" of EESSI and issue alerts when it detects problems (e.g. abnormally long response times, high number of message rejections, a node downtime, etc.). The alerts must be configurable. If the system detects malfunctioning, it must alert the administrator, e.g. by . The alert must be configurable to ignore certain types of malfunctioning, e.g. during known maintenance. It must be possible to set thresholds per administrator, e.g. notify field administrators immediately but escalate the problem to supervisors only when certain thresholds are met. Call for Tender VT/2008/019: Administrative Specifications Page 23 of 101

24 No more than one alert must be sent per error and per administrator until the administrator resets the error notification. As usual in this call for tender, given the short timeframe, it is expected that most, if not all, these requirements, can be met by adopting an off-the-shelf application monitoring system, common log libraries, and the like. The tenderer should privilege integrating these services in EESSI, rather than developing new systems Statistics The aim of collecting statistics will be that of observing how the Regulations and the EESSI system - are implemented and functioning. Secondarily, statistics will help Member States identify problems in the processing of claims with a view to improving their services to the citizens. The CN will only be allowed to read SED envelopes for the purpose of forwarding them to their destination Access Points and will never 18 un-encrypt the message contents. Therefore the statistics will be collected from the data on the envelope and the contractor, with the approval of the Commission, must define the envelope bearing statistics in mind. The required statistics concern the volume of messages (number and size) and are to be broken down by: countries social security sectors access points competent institutions (liaison body when the CI is missing) business flows (for instance, settlement of pension claims ) by a periodicity to be determined by the administrator The system must allow the individual envelopes that are forwarded to be stored in a file for later statistical usage. The contractor is not requested to embed any statistical packages into EESSI. The data to be processed must be exportable in the usual formats so that the raw data can be processed by standard statistical tools that the Commission already uses and operates. The output statistics should be produced in a format that allows easy data manipulation (e.g. CSV and/or open standard format) Operational Aspects Since the coordination node will host the EESSI information repository and allow the exchange of social security data, it will be necessary to operate it 24 hours a day, 365/6 days in a year. 18 The successful tenderer is to study the compatibility between this and other requirements and that of ensuring security. Should there be a conflict, this requirement will be re-discussed with the Commission. Call for Tender VT/2008/019: Administrative Specifications Page 24 of 101

25 L1:FS-79 The coordination node shall be operational 24 hours a day, 365/6 days in a year For the purposes of supporting the current FTP-based electronic exchanges, the tenderer will note that there is an FS-80 in the Functional Specifications provided in Annex A4. The FTP protocol will continue to be supported using the existing infrastructure during the transitional provisions that may be agreed by Member States in Council Access management Access to the CN functionalities must be allowed on a permission basis. Different types of EESSI administrators will have access to different parts of it. For instance, within the Directory, while AP administrators will be allowed to edit details about their own countries' CIs, only the Commission's central administrators will be allowed to edit AP's details and grant them their rights. SED checking facilities should be accessible to all EESSI end-users, including those in the CIs; however, editing SED structures should be restricted to central administrators (although AP clerks will be allowed to upload language versions of flow, SED and data titles and labels). This calls for an access control management system. Typically, this should define roles and profiles. The granularity must be fine enough to control specific actions. Just to take a few examples, it is expected that the ability to create and edit entries in the Master Directory would be different rights such that an administrator can create new entries for each Competent Institution but delegates to the Competent Institution the rights to edit its own entry. The access control must be able to recognise not only individual users and rights, but also groups of users and bundle of rights to ease user management. However, it is left up to the tenderers to specify what access system they plan to implement for this purpose and possibly suggest that adoption of standard systems in existing applications is appropriate Console The Coordination Node will operate in the Commission's data center and physical access to the server will be limited. Therefore an administration console must be available that enables administrators and other super-users to monitor, administer and configure the various components. The console must be remotely accessible and preferably web-based. It is expected that different administrators will be assigned to different components of the Coordination Node. For example, the Directory may be under the responsibility of some people, the messaging component under the responsibility of other people, while the repository under the responsibility of others, some of whom may be also responsible for the messaging component. Each has different responsibility and therefore limited control over the component (e.g. certain sections in the repository, certain routes in the messaging component and the likes). Call for Tender VT/2008/019: Administrative Specifications Page 25 of 101

26 Hence, access to the console must go through the Access Control List (Access Management) and, as already covered, this must have fine grain rights to give users just the rights they need to perform their job The Reference Implementation As already explained above, the Reference Implementation (RI) is a set of software applications that implement the functionality of the International Part of the Access Point (IPAP). Please remember that, in this project, the Reference Implementation is one of the implementations of the message protocol. Member States may develop and use their own IPAP implementations based on the same protocol. It will consist of a set of modules providing common functionalities of the Access Point s services with a well-defined interface for the exchanges of data with the national part of the Access Point (NPAP) that will be developed by the Member States. Figure 7 below illustrates the separation between the national and international domains. Figure 7 National and International Domains in the Access Point It will also connect to the CN with a view to exchanging messages with AP in other countries (more specifically, their IPAPs 19 ). The Reference Implementation developed by the contractor will remain the property of the Commission. The Commission will provide its maintenance and support. The Commission will make available the software (for free) to the Member States that decide to use it. 19 Once again, note that some countries may decide to develop their own IPAP. The obligation to go through the CN is meant to hide the uncertainty as to which IPAP application will be sending/receiving SEDs. Call for Tender VT/2008/019: Administrative Specifications Page 26 of 101

27 Figure 8 illustrates the architecture of the Reference Implementation. The RI has the following key features: Supported SED formats: XML-encoded SED, which is the native EESSI format Access Point services Conversion Directory Messaging Monitoring and logging Security Additional services Human-assisted routing, on an optional basis and entirely at the discretion of each Member State Interfaces with National Part of Access Point File system Database (RDBMS) Web services Java Messaging Service - JMS Enterprise Java Beans - EJB Interfaces with national on-line systems Web services Java Messaging Service - JMS Enterprise Java Beans EJB Other, to be defined Lest this is overlooked, we want to stress that the use of JMS, EJB, Database and other communication protocols are for the interfaces with the national part of the Access Point. On the international side, the exchange is solely based on the SOAP flavour of Web Services. Please note that the International Part is essentially a messaging service, it does not specify a global, trans-national, JMS or EJB deployment. Call for Tender VT/2008/019: Administrative Specifications Page 27 of 101

28 Competent Institution National Network National portal Portal database XML conversions LDAP Directory server Directory store Access point national part File system Database Web services JMS EJB Input- output queues EMS Encryption/ Decryption Message Transport Agent MTA MTA store Input/ output queues International message transport module SED validation File packaging Interface with national on-line systems EESSI International Network EMS Store Human-assisted routing front-end Clerk Security Monitoring and logging Web services interface JMS interface EJB interface Other to-be-defined interface Figure 8: Reference Implementation architecture Infrastructure to host the RI The RI is an application that implements the functionalities of the International Part of the Access Point that must be installed on the hardware provided by Member States' Institutions. The contractor must specify the target infrastructure (servers and operating systems) to host the RI. Member States are responsible for providing and maintaining the infrastructure as well as its connection to stesta. Since the software must be built on an application server, it should be platform-agnostic and allow Member States to procure the platform from their usual suppliers. Moreover, given the expected volume of exchanges, in specifying the infrastructure, the contractor must bear in mind the expectation that Member States should be able to host their RI on an entry-level server 20. Please note that there will be more than one Access Point in several countries. In 2007, countries limited themselves to having a minimum of one and a maximum of five Access Points each. Early in 2008, most countries have drastically reduced the uncertainty as to how many AP they will have and the total ranges from less than 60 to between 70 and 80. The breakdown may be found in Annexe A3. 20 However, this may need to be replicated to implement failover. Call for Tender VT/2008/019: Administrative Specifications Page 28 of 101

29 The contractor will have to provide remote support to countries in their installation of the Access Points. The table in Annexe A3 is provided with a view to helping the tenderers budget for this operation Web Interface for the clerk The concept of web interface for the clerks was introduced as a low cost and an easy-toimplement solution to provide Competent Institutions with the means to exchange electronic documents in EESSI. This solution will be more useful for institutions with very low volume of exchanges which would make it un-economical for them to invest in national developments. The Web Interface for the clerks is a virtual office aiming at assisting them in preparing, sending, receiving, storing, printing, etc SEDs. It should also provide the clerks with the facility to reject a received SED in specifying the reason for the rejection (e.g. wrong Member States, wrong Access Point, etc.) or forward a message to another institution when the final destination is known by the clerk. Be warned that not every Competent Institution will use the Web interface or will use them for every flow: it is expected that most Competent Institutions in the Member States will integrate the SED and flows in their national application, providing a more convenient, unified (since it covers both national and international flows) interface to their clerks. The web interface is a fall-back solution, either for Competent Institutions that have few international exchanges or for those flows that are infrequent, thereby allowing clerks to fill in SEDs on screen before dispatch. Figure 9: Access point national part, web-interface and statistics A clerk of a Competent Institution will use the Web Interface for the clerk either to fill the data in a SED via Web forms or retrieve from the interface SEDs sent by counterparty Competent Institutions. The interface will allow storing incoming or outgoing SEDs in the access point database. For the purposes of the EESSI architecture it is assumed that the Access Points will implement a database in which different types of data will be stored, including SEDs and associated data (e.g. logging, such as which clerk prepared a certain SED ), administrative data (e.g. Institutions that are entitled to use the interface) and statistics (see ). Call for Tender VT/2008/019: Administrative Specifications Page 29 of 101

30 Multi-lingual issue Although the version of the interface developed by the contractor will be in English, the interface will be multi-lingual and the architecture of the software should be built in such a way that the integration of other languages will be simple and easy, using good practices in the industry (e.g. localization APIs). Member States will be responsible for producing and uploading their own language versions but they must be given the appropriate tools such as a localization API. The contractor will use best-practices and will test to ensure that the whole application can be localized easily. Possible tests include generating fake translation (e.g. "pig latin") by software to spot screens that are not fully localizable. Integration of the business logic The interface should also integrate the business logic of the business flows (i.e. when a clerk receives a specific SED, they should have a reply button that prompts them to fill and send one right away or at a later date or use a more suitable response SED). This facility must draw on the flow, SED and data item definitions that will be available in the CN 21. A powerful help tool should assist the clerk when preparing and answering SEDs. It should for instance have the possibility to consult the business flows. The interface should provide all the assistance that would be possible to help the clerk in his daily work. The tenderer is free to propose in the answer any modern help mechanism to guide the clerk when initiating and answering SEDs. Since some SEDs 22 are different for each Member States (i.e. the data required by each Member State are different) the interface should in this particular case display only the data required by the Member State of destination (provided, of course, that the per-country information is stored in the UML model). In this particular case, once the Member State of destination is provided by the clerk, only the data required by this Member State should appear on the screen. Ease of use It is expected that the interface will be used primarily by clerks who process few international claims or for infrequent claims (claims that are frequent are typically integrated in the national applications) so ease of use is of paramount importance. By ease of use it is meant the provision of contextual help (as explained above) but also following good practice in interface design (e.g. a rich interface in AJAX or Flex, etc.). Finally, since the interface will be used by clerks from Competent Institutions from all over Europe, it must be compatible with all the major browsers, including at least Internet Explorer 6 and above, Firefox, Safari and Opera). Workload 21 See above. 22 Tenderers will see from annexe T2 (data) that the data to be sent within the "pensions" and "accidents at work and occupational diseases" sectors changes with the receiving country. Call for Tender VT/2008/019: Administrative Specifications Page 30 of 101

31 At the time of writing, taking into account the previous specifications, it is expected that no more than 500 clerks will access the web interface concurrently for one Access Point. It is expected that this low figure can be accommodated through an entry-level server. Flexibility and integration with Competent Institutions It is important to keep in mind that the web interface for clerks is not the only tool available to clerks in their day-to-day business. Quite the contrary! Since it is primarily intended for infrequent flows or Competent Institutions that exchange little information internationally, clerks will use very infrequently. Consequently it must be flexible to integrate, as much as possible, in their working environment and adapt to the practices of the Competent Institutions. Some examples (but not limited) of the flexibility required include the ability to define a minimalist workflow for claims. In some Competent Institutions clerks are empowered to process a claim from start to finish and therefore once they have received a claim, it should not be forwarded to someone else. Other Competent Institutions may prefer to validate the claims (SED messages in EESSI practical terms) through a supervisor before issuing a formal reply. Therefore it must be possible to forward the claim to a supervisor who would be sending the SED message on to the destination country by approving it or back to the "preparator" by rejecting it, with comments. Another aspect of the flexibility is specialisation. Some Competent Institutions may have specialized clerks that process only certain claims. The web interface must only present clerks with messages that they are allowed to process. Finally let us not forget that people get sick so a mechanism must exist to alert a supervisor or a colleague if a SED has not been processed within a given time-frame. The time-frame will be a parameter that will apply to and be set by individual Competent Institutions But, most importantly, the first stage in integrating with the clerk working environment is to retain its username and password. Competent Institutions will have stored those in an LDAP server or through a database or (for the small ones) may be able to provide them through files. The web interface for clerks must provide a default login system but it must be able to interface with the many authentication schemes used by the Competent Institutions either through standard protocols (LDAP, Apache.htaccess password files, etc.) or through plug-ins (see the section on plug-ins below). Design Considerations Bearing in mind that there are hundreds of different types of SEDs 23 and that the SEDs will evolve over time, the web interface for clerks must be designed with an eye towards its maintenance. Practically, this requires the web interface for clerks to be designed around a flexible form editing engine that will be tailored to each SEDs. As much of the configuration information as possible will be extracted from the UML models, of course. 23 Please refer to Annexes T1 and T2 as regards flow and SED size and diversity. Call for Tender VT/2008/019: Administrative Specifications Page 31 of 101

32 Note that it is not acceptable to hard-code the processing of the SEDs in a closed application that would require extensive software development. Ideally, the form should work on the XML document in its native form. Again it is expected that the contractor will integrate a form editor (comparing with tools like Apache Cocoon, Adobe LifeCycle or JPublisher may serve help the tenderer understand the needs of the Commission) instead of building something from scratch. Updating Master Directory entries One task of the Access Point clerks will be that of keeping the Master Directory up-to-date. To do so, they will need an interface. Such interface could be integrated in the interface that will allow them to process SEDs or separate from it. Generally speaking, it is likely that, in countries where the web interface for the clerks will be used for most SEDs, the same clerks that process SEDs will also maintain the Directory entries The interface with national application (NPAP) The interface between the national and international part of the access points will be implemented as queues using the following five different alternatives: File system Database table(s) Web services Java Messaging Service JMS Enterprise Java Beans EJB Queues based on file systems and databases are discussed below in section EMS input and output queues. The above three additional options for implementing queues have a wide scope and should give Member States a great deal of latitude in how the exchanges of SED between CIs and the Reference Implementation could take place. Web services is the most generic and results in a low coupling between the national and international parts of the AP. Associated Functional Specifications L1:FS-32 Access Points shall timely (i) route messages to Competent Institutions and (ii) timely process outbound messages and deliver them to counterparty access points. L1:FS-33 When necessary and for the purposes of routing SEDs to Competent Institutions, access points may inspect parts of a SED; such human intervention shall be timely completed. L1:FS-34 For the national data traffic, access points shall implement security measures complying with the national legislation for the protection of the SED, as well as with the European Data Protection Directive. L1:FS-35 Message headers submitted by Competent Institutions shall be checked and validated. Only when all relevant checks and validations have Call for Tender VT/2008/019: Administrative Specifications Page 32 of 101

33 been successfully passed the corresponding SED will be transported to the counterparty Access Points. L1:FS-36 Access Points shall keep full records on the exchange of social security documents (e.g. SED, paper forms, other electronic files) with the Competent Institutions they serve. On the basis of such records, they shall also produce statistical reports for the exchange of SEDs. L2:FS-37 Access Points may provide a notification service to Competent Institutions for incoming SED. Member States may also host a national portal that will enable the exchange of SED at the national level between Competent Institutions and Access Point(s); it will also provide a dedicated data entry application facilitating the entry of data by social security clerks Messaging The EMS is at the very core of the access point services, and more specifically it is the single most important component of the international part of an Access Point. EESSI Messaging Service - EMS Input and output queues Encryption/Decryption Message Transport Agent MTA MTA store Input/ output queues Message transport module EESSI International Network SED validation File packaging Interface with national on-line systems EMS Store National Network Front-end Front-end National on-line database National on-line database SED Compound files exchanged in EESSI international domain National format of electronic documents exchanged with on-line databases Figure 10: EMS architecture Call for Tender VT/2008/019: Administrative Specifications Page 33 of 101

34 As Figure 10 depicts, the EMS logical architecture has the following components: EMS input and output queues In order to have a loose coupling of the EMS with other components of an Access Point, it is proposed to use input and output queues. In this way, EMS can run independently of other components of the Access Point software. There are several ways with which input and output queues must be implemented, listed hereafter. The first two are important since SEDs are often stored in queues as files. File system. SEDs can be written in a file system to designated directories. For instance, when a file is written to a designated directory, EMS will then treat this file as a SED to be sent to a counterparty access point and will start the processing. Similarly, when a SED is ready to be delivered to the national part of the access point for routing to the Competent Institution, the EMS will write the file (following a customizable naming convention that allows Member States to extract routing information from the file name) to a designated directory. The national part will poll the designated directory(ies) for newly deposited files and will collect them for routing to Competent Institutions. When file systems are used to implement queues, it will be necessary to implement either (i) a polling scheme with which an application will check periodically for the addition of new files or (ii) rely on the facilities of modern operating systems to post asynchronous notifications to applications when the contents of a file directory have been modified. Database. A Relational Database Management System - RDBMS can be used to implement input and output queues with a database table used as one queue. Entry into the input queue will involve the insertion of a SED into a row of a designated table. Reading from the output queue will involve fetching the contents of a table. It is clear that the RDBMS must support the storing of documents in its tables. A database implementation of the queuing mechanism can use database triggers to notify applications about the insertion in the queue of a SED. Webservices a service can be used to interact with the queue (deposit or retrieve messages). Options to the call should allow specifications to request conversion service, validation, etc. JMS messages can deposit or retrieve into or from the queue through the JMS API. EJB a façade can be designed allowing clients to interact with the queue, offering the same services as the other APIs. Note that the national part may (in fact in the vast majority of situations, will) implement further routing and exchanges to send the message to the Competent Institution 24. Therefore the interface must copy the message envelope to the national part. It may be passed through dedicated fields in the database, the file name for the file interface, a routing bean for the EJB interface, etc. Again, it is important to differentiate the interfaces with the national part which will provide a plurality of protocols from the international protocol which will use the SOAP flavour of Web Services exclusively. 24 For the relationship between Access Points and Competent Institutions, please refer to Call for Tender VT/2008/019: Administrative Specifications Page 34 of 101

35 Queue/web interface routing By reviewing the specifications so far, it becomes apparent that when a message is received by the Access Point, it can go one of three ways: it can be 1. forwarded to the Competent Institution, through the NPAP and ultimately through the output queue, or 2. processed by the clerks through the dedicated web interface or 3. sent to the manual routing environment which will forward it to its final destination (ultimately some other NPAP or clerk interface). The Reference Implementation must therefore implement internal routing that will determine how to process the message. Functionally, the internal routing must be flexible enough to accommodate for a wide range of very disparate situations. Indeed it is important to keep in mind that the Access Point is the contact point for a number of Competent Institutions and that there can be up to several hundred Competent Institutions connected to a single Access Point. There are two aspects to consider, security and processing. Security is trivial to understand: a Competent Institution must not be able to retrieve or view (either through the web interface or through the NPAP) messages that are routed to another Competent Institution. Likewise clerks, through the web interface, can see only those messages that they are authorized to process. For example, if a clerk is authorized to process only a certain type of claim, it should only see messages related to those claims. The Competent Institutions are free to organize themselves as they see fit so the system must provide considerable flexibility, allowing Competent Institutions to define the authority of their clerks over certain types of claim. The second problem, i.e. processing, may not be as obvious since it is expected that each Competent Institution will have a different level of integration. The two easy scenarios are to either 1. process every message through the web clerk interface or 2. process every message automatically by routing them through the NPAP. The reality will be somewhere in between: Competent Institutions will want to automate their most frequent exchanges and process the other exchanges through the web clerk interface. Since different Competent Institutions deal with different aspect of social security, it is inevitable that they will automate different exchanges. For example, Competent Institution A may want to automate exchanges 1 to 10 but process all the other exchanges through the web clerk interface whereas Competent Institution B will only automate exchanges 20 and 30. The internal routing must therefore be based on queries on the message envelope. Based on the value of a combination of fields, the message will be routed through one of the three options above. Obviously it must be possible to define a default route if the message does not match any of the queries. There are two possible solutions, namely either Call for Tender VT/2008/019: Administrative Specifications Page 35 of 101

36 the reference implementation offers rule-based routing that enables the Access Point administrators and the administrators of the Competent Institutions (via remote access in the later case) to configure the routing they need, based on queries in the message envelope, or the output queue interface is modelled after IMAP (only in concept since, obviously, the RI will be implementing the five queue protocols outlined above, not the IMAP protocol), i.e. a protocol that allows the NPAP to query the headers of the messages, mark messages as read/unread, lock messages for a certain duration (making the message unavailable while a clerk is working on it), download and delete messages. In the first approach, the Reference Implementation would be in charge of routing the message and would provide different queues (similar to IMAP mailboxes) for each (functional) clerk in the Competent Institution plus one queue for the NPAP. The queues for clerks would be accessed through the web interface whereas the NPAP would access its own queue. In the second approach, the NPAP would download the message headers, and decide which messages it needs to download and which messages it should leave in the queue for the clerks to pick through the web interface. The web interface for clerks would use the same technique of retrieving the message headers to decide which messages to download based on the competence and authorization of the clerk. Other technical implementations may be possible so long as they satisfy the fundamental requirements outlined above, and the tenderer is required to describe their proposed solution in their tender SED validation Functional specification FS-35 requires that data submitted by Competent Institutions will be checked and validated and only when all relevant checks and validations have been successfully passed the corresponding SED will be transported to the counterparty Access Points. This specification has two parts; one concerning the national part of information exchange and a second one concerning the international one. The former are discussed in the section above. The subsequent discussion considers the latter. What is fully within the scope of EESSI is the validation of a SED, since all SED must conform to all applicable EESSI standards. Depending on the encoding of a SED the following validation activities can be undertaken: XML documents: Validation that the document fully conforms to the corresponding XML schema, optionally followed by Schematron rules. MTF: Ad-hoc checks as agreed upon by the Technical Commission Common flat file format: Ad-hoc checks as agreed upon by the Technical Commission For SED destined for transport to counterparty Access Points (outbound), those checks may be omitted if the SED was prepared with software running at the Access Point. This is the case when clerks use their web interface. For instance, if an XML-encoded SED was prepared Call for Tender VT/2008/019: Administrative Specifications Page 36 of 101

37 at the access point by a clerk, it is expected that the SED conforms to all standards. However, for incoming SEDs, received from counterparty access points (inbound), the validation should be performed. The contractor is to provide for a SED validation framework in the RI that Draws from validation rules that will be stored in the CN (these will be submitted to the Administrative Commission for approval, with a view to applying them to all countries) Implements the rules on o Inbound SED received from other countries o Any SED, on request via the web-interface for the clerk o SED building in the web-interface for the clerk Allows flagging or outright rejection of non-complying SED During the contract period some SED validation rules may be implemented. The purpose of these will be mostly to test the validation framework. It is likely that the bulk of validation rules will be approved slowly and after the contract completion. The contractor is expected to provide for a validation framework that will allow new rules to be easily defined, via a simple and at the same time powerful syntax. Once again, existing product should be favoured over specific development. Although the contractor is free to propose any validation framework, its expressiveness must be at least equal to what is supported by the combination of a document description language such as XML Schema (W3C Recommendation) or Relax NG (ISO/IEC standard) and an assertion language such as Schematron (ISO/IEC standard). Tenderers should give an indication of how they plan to approach this requirement Encryption/decryption Encryption facilities will be available for the exchange of information between access points, both at the transport level (Transport Level Security TLS) and also at the message exchange level of the EMS. The encryption/decryption functionality considered here concerns encryption at the level of an individual SED, which is different from that at the transport or messaging levels that will be guaranteed by the stesta Network. All SEDs within EESSI should be encrypted at the message level on a transparent way for the clerks. Between Access points all SEDs will be encrypted using the Web-Service security. Tenderers are asked to consider whether the agreement in the Technical and Administrative Commissions to use WS-security runs counter to the assumption that no decryption/re-encryption will take place at the CN. Tenderers are asked to consider any conflict and suggest solutions, for instance whether CN can or should be set up as a proxy File packaging The motivation for packaging several SEDs into a single, large compound file is to follow, where necessary and appropriate, the batch nature of Call for Tender VT/2008/019: Administrative Specifications Page 37 of 101

38 electronic document exchange between Access Points 25. Currently, the electronic exchanges in TESS are performed in batch fashion, with files being exchanged in the order of up to tens of MB. As this batch exchange of SED will continue in EESSI, the File packaging component provides the basic building block for exchanging information in batch. A compound file consists of several SEDs and a header with information such as the sender and receiver Access Point 26, according to the SOAP specifications (MTOM). Compound files can be encrypted and compressed Message Transport Agent The Message Transport Agent MTA is the component of the EMS which is responsible for all electronic exchanges with the counterparty Access Points. From the international perspective of EESSI, it is one of the most critical elements of the EESSI platform. It consists of the following five modules: MTA input/output queues. Files to be transported by the MTA will be placed in input and output queues, which will be similar to those of the EMS (described above). In Figure 10 it is proposed that MTA input and output queues are different from those of the EMS itself in order to create a loose coupling between the MTA and the rest of the EMS. MTA store. The MTA store is a storage area in which the MTA stores files in transit, that is, files being transmitted or being received. When files are being transported across the EESSI International Network, those files are read into the memory of the MTA. Any crash of the MTA will result in a loss of file(s) in transit. The MTA store will provide persistency, thereby increasing the reliability of the MTA and the EMS Interface with national on-line systems. The interface with national on-line systems deals with responding to synchronous requests, where the response should be given in a matter of a minute (e.g. when processing entitlements to healthcare). Checking and verifying the postings of workers requires a response in about ½ hour, which can be considered as a near-synchronous request-and-response requirement. Due to the tight response requirements, time-critical messages will not take the usual processing route in an access point. Instead, the message transport module will promptly invoke the services of the Interface with National on-line Systems module. The latter, after performing a minimal set of validations (e.g. person identity is sufficiently described) will post a query into a front-end to a national on-line database and, where that is not possible, to the appropriate AP. 25 The need for packaging was expressed by some countries. Currently, packaging makes sense in the context of paper exchanges. It is possible that, once CIs get used to electronic exchanges, the need for packaging will be felt less. 26 In addition, there may be a need to include a list of enclosed SED numbers, with a view to enabling the CN to ensure uniqueness of SEDs, i.e., that a SED is sent once and only once and other information similar to the single SED envelope. Call for Tender VT/2008/019: Administrative Specifications Page 38 of 101

39 International message transport module. The function of the Message Transport module is to carry out the exchanges with counterparty access points. It will be implemented using the EESSI Web services stack. EMS Store The EMS Store is a storage area that holds SEDs, compound files while in processing or in transit within the EMS, as well as records on the processing and transport of all documents/files. EMS provides horizontal services to all other components of the EMS. The EMS store consists of the following two parts: File-system storage, which is a store area located in a part of a file system RDBMS storage, in which operational data are kept about the transport and processing of SED Monitoring and logging in the RI There are two functional specifications regarding the monitoring and logging facilities. Monitoring Monitoring in real-time the performance of a server-based application is important in establishing its operational status and help to identify the root causes of problems when they arise. To give an example, server-based software applications such as platforms (e.g. MS-Exchange), relational databases (e.g. Oracle, DB2, MS-SQL Server) provide several realtime performance counters with which operators are able to inspect how the application performs. For the same reasons, it is important that computer operators be able to assess in real-time the performance of the access point software applications. L2:FS-61 Metrics will be collected in real-time (performance counters) for a variety of parameters (e.g. data transfer rate, message transfer rate, bandwidth utilisation etc.), such that the status of the services be quantitatively established. FS-61 is concerned with the collection of real-time performance metrics such as data transfer rate, message transfer rate, bandwidth utilization and will enable the real-time establishment of the status of the access point services. The RI will handle message transport issues, including support for the CI clerks. For this purpose, the RI will need monitoring tools to track messages and problems. Tenderers are requested to indicate which monitoring features will be available with their proposed architecture. The contractor is to provide the usual monitoring facilities to trace the source of any problems and errors. For example, the following parameters are known to be useful: time while the system is up, connection attempts: their status, duration, the message ID, the message status in the queues and times in queues, whether it s inbound or outbound Call for Tender VT/2008/019: Administrative Specifications Page 39 of 101

40 connections and the address of the counterparty system. In case of error, the error message. Queue sizes, in number of messages and bytes Any congestion problem or other failure with the time stamp and message ID The fields in the message envelopes. The output of monitoring and logging must be exportable in several formats, including CSV. The contractor must provide an interface to query on any parameter defined above. Queries need not be in real-time (the use of log files, as opposed to a database, is acceptable). The contractor should note that there will be no data protection issue since the information above (including that on the message envelope) is not personal data. The RI system administrator must be given the option to control how long the logging data is kept, make new log files periodically, or limit the total size of the log. If the system detects malfunctioning, it must alert the RI administrator e.g. by . The alert must be configurable to ignore certain types of malfunctioning, e.g. during known maintenance. No more than one alert must be sent per error until the administrator resets the error notification. Since the RI will be deployed in several Member States, it is important to be able to detect and track bugs remotely, so the RI must include crash reporting tools that enable the administrator to prepare a bug report with all information that can be useful to the developers. For instance, tools such as Mozilla TalkBack or Google Breakback, Windows Error Reporting may inspire the tenderer in its thought processes. Data logging The data logging function involves (i) the collection of data about the SED exchanged both with counterparty access points and with Competent Institutions, and (ii) data about how SED are processed internally at the access point. More specifically, it is concerned with collecting data about: Exchange of SED and accompanying electronic documents Exchange of SED and compound documents (consisting of several SED) with counterparty access points Routing, dispatch and reception of electronic documents (in national format) to/from Competent Institutions Processing of SED Conversions of SED to different EESSI formats (e.g. XML to EDIFACT) Packing of SED into compound files consisting of several SED Any file encryption performed at the access point for the purposes of transmitting files to counterparty access points. The data sets collected from the data logging functions will have to be stored into a database residing at the Access Points. This Data logging database will provide the underlying data with which statistics about the electronic exchange of SED will be compiled. FS-62 concerns Call for Tender VT/2008/019: Administrative Specifications Page 40 of 101

41 the logging of the activities relating to the transport of SED outside the boundary of the Access Point and any message processing within the access point (e.g. conversions). L2:FS-62 All activities relating to the transport of SED outside the boundary of the access point and any message processing within the access point (e.g. conversion) shall be logged. It includes keeping logs of (i) SED submitted from Competent Institutions for transmission to counterparty Member States and (ii) SED forwarded to Competent Institutions Statistics The aim of collecting statistics in RI will be that of observing how the Regulations and the EESSI system - are implemented and functioning at national level. The IPAP will only be allowed to read SED envelopes, for the purposes of making messages available to the NPAP for routing to the destination CI. It is expected that the national administrators will require statistics which are similar to those collected at the CN level for the whole EESSI. These concern the volume of messages (number and size) and are to be broken down by: countries social security sectors access points competent institutions (liaison body when the CI is missing) business flows (for instance, settlement of pension claims ) by a periodicity to be determined by the administrator The contractor is not requested to embed any statistical packages into EESSI. The data to be processed must be exportable in the usual formats so that the raw data can be processed by standard statistical tools that are probably already in use. The output statistics should be produced in a format that allows easy data manipulation (e.g. CSV and/or open standard format) Interface for manual routing Although optional, the manual routing is one of the main functions of the AP. It is indeed sometimes not possible for the sender to identify the final recipient competent institution. In this case the sender in the sending country may decide to simply send the SED to the Access Point 27 of the receiving country, without specifying the destination Competent Institution. In this case the routing of the SED towards the appropriate national competent institution becomes the responsibility of the Liaison Body. The Liaison body will perform this routing function either automatically by dedicated routing software or simply manually. To assist the 27 A country may have thousands of Competent Institutions but maximum five Access points. It is assumed that, while a sender could have a doubt on which Competent Institution (CI) they need to send the SED to, they will always know which Access Point the SED will go through (or, rather, "to" in case the CI is not known) Call for Tender VT/2008/019: Administrative Specifications Page 41 of 101

42 manual routing, the RI must offer a dedicated interface to the clerk (with access control mechanism) where they could consult the incoming SED and decide to which other destination to forward it. The functionality of this interface is quite simple. The clerk should be in a position to quickly screen the incoming SEDs in a queue and decide on the next action to perform, such as To forward the SED to the national appropriate Competent Institution by clicking on a forward button, introducing the address of the national competent institution and sending the SED. To print the SED to forward it through another mail system (normal surface mail or any other mailing system) To save the SED in a PDF like format To reject the SED because they could not determine the final destination And any other actions the contractors may consider as relevant and appropriate. This Web interface could of course be integrated into the Clerk Web interface already described above, and it is up to the tenderers to make proposal Transport and routing The fundamental function of the EESSI message service is the sending and receiving of messages. The EMS must be able to receive incoming messages when a sending site wants to send a message. In addition, it must be able to receive messages by polling a specific service about incoming messages. The RI must implement the communication protocol; see Protocol Design and Document below L2:FS-45 EMS shall provide functionality for receiving unsolicited messages from another sending EMS site, or by polling a sending EMS site. In the cases of checking entitlement to healthcare or the posting of workers (currently E101, but to be replaced in the near term with the posting SED), EESSI needs to provide responses in a faster time-frame than other messages. Therefore, those messages should be routed along a separate path (see section 3.1.6). In the former case, the sending of the request and the receiving of the response has to be made within the same connection (or session). L1:FS-46 EMS shall provide facilities for the exchange of messages within a single session in a query and response paradigm. The above requirement amounts to EMS providing a synchronous service. This needs to be foreseen. L2:FS-47 EMS shall provide status information to the sending side 28 about the successful or otherwise completion of the message transfer. 28 In our case, the "sending side" is always the Competent Institution that sent the SED message. Call for Tender VT/2008/019: Administrative Specifications Page 42 of 101

43 To support automatic dispatch of SED to Competent Institutions, messages should contain headers specifying how the message will be processed, routed and delivered to their final recipient. L1:FS-48 Message headers shall contain all the necessary data for the further processing, routing and delivery of messages to their recipient. L1:FS-49 Message headers shall be processed in a standardised way The EMS will provide the underlying data transport functionality in EESSI. As such, it must be able to transport files irrespectively of their formats (e.g. XML, plain text, binary). There must be no dependencies on the particular file being transported. Message addressing and processing must be specified outside the file being transported. L1:FS-50 EMS shall be able to transport any type of files. All information specifying addressing, routing and processing of files shall be contained in the message header The conversions On EESSI, between access points, all SEDs will be formatted in XML. However in order to preserve investments made in some Member States that still use legacy or proprietary formats at national level, the access points will provide bidirectional conversions between the following formats: XML to/from MTF XML to/from common flat file format XML to XML, in transforming between different versions of an XML The contractor should also provide, in the conversion module, the transliteration of non-latin- 1 characters to the Latin-1 character set. It will be based on a unique, standard mapping of characters. As always the tenderer is encouraged to rely on existing modules and solutions to save time and ensure quality delivery. Therefore it is perfectly acceptable (although not required) that the ending supports conversion to and from more formats, e.g. legacy formats (e.g. EDIFACT, CSV), alternative web service formats (e.g. JSON) or publishing formats (e.g. HTML, PDF, OpenDocument). As regards the flat file format, the contractor is to propose a simple and user-friendly format Security Obviously one aspect of security is the encryption facilities that are provided by the Messaging Services. This has been covered in great length in other sections (see ) and therefore not repeated here. The second (and possibly more important) aspect of security is the securing of the Access Points and the Coordination Node. Both need to be resilient to common attacks such as buffer overflow, denial of service, command injection, un-validated parameters and the like. The problem is compounded by three factors: Call for Tender VT/2008/019: Administrative Specifications Page 43 of 101

44 The project will integrate different libraries, each having their own security concerns and evolving at their own rhythm. The project is deployed on a closed network which means operators and developers tend to rely on the security of the infrastructure. Complacency then becomes a risk (e.g. because operators may forget basic security principles), especially given that the Access Points may be connected to stesta through a national network that may be less secured. The project will be developed under a firm schedule. However, it is important to remember that social security information is sensitive and must be treated as such. Furthermore, in case of an incident within the national network of a Member State that was linked to the Reference Implementation, the responsibility of the Commission could be engaged. Therefore the tenderers need to establish security teams and have them apply proper software engineering practices (such as but not limited to code review, security training, security testing, etc.) to guarantee the quality of the delivered software. The teams will also be involved in the library and product selection. It is important to note that their role will not be limited to cryptographic aspects. The security team must be staffed with technical experts and, hierarchically, report to management level above the project manager in order to be effective. The contractor will describe the security policies being proposed and the steps taken to implement those in the tender. The tenderers will describe their proposed security policy and their experience in successfully establishing security procedures Interface for the data mapping and conversion As discussed above, a conversion facility will be provided. The conversion facility will be built around a graphical or scripting language. This language must have at minimum the expressiveness of XSLT 2.0 or XQuery 1.0. Another language can be used but it cannot be less expressive. Two classes of applications for the conversion facility are envisaged, namely: Use of the raw conversion engine, with a mapping prepared by the Member States pre-configured conversions such as the MTF-to-XML conversion (and its reverse XML-to-MTF conversion) outlined above (see ) The difference is in the amount of work needed to use these conversions. In the latter case, the conversion is fully operational and already configured. If you input a file in the proper format, it outputs the converted message immediately. The mapping is provided in the distribution of the Reference Implementation. By contrast, in the first case, the conversion engine needs a mapping before it can be used. The mapping is not provided with the Reference Implementation; rather, it will be developed by the Member States as part of their setup routine. Call for Tender VT/2008/019: Administrative Specifications Page 44 of 101

45 It is expected that the first case will be covered by standard conversion engines, whereas the second case might need some development. Still when preparing mappings (first case), it would be helpful to benefit from a number of conversion routines and features to map data. For example, the usual methods are: date conversion and other functions to manipulate dates code conversions (e.g. converting from ISO 2 characters country code to 3 characters country code or to other standards such as the car plate codes) functions to aggregate numerical data (sum, average, etc.) While building the maps for the MTF-to-XML and XML-to-MTF conversions, the contractor will need to build these conversion routines and many more. We expect the contractor to establish a list of functions that will be useful for many mappings and to make those available as part of the Reference Implementation, in a library of conversion routines. They will therefore be available to the mappings developed in the Reference Implementation but also to those that will be developed by the Member States themselves, thus saving time and effort. Furthermore, the library must be designed in such a way as to be extensible, allowing Member States to contribute to the library when they build their own mappings. A system is envisaged whereby a Member State, having completed a mapping, can select a number of conversion routines that it prepared and export them to the library, thereby making them available to other Member States. This is not unlike the shared code repositories deployed in Open Source projects where a base code is being provided but anyone can enrich it. One possible solution would be to host the conversion routine library in the information repository and provide appropriate UI elements to load, browse and contribute within the conversion engine. The contractor will need to analyse this and make a proposal Plugins As explained earlier, Member States are free to develop their own IPAP as long as it conforms to the EESSI protocols. This is because some Member States fear that the Reference Implementation may be not flexible or powerful enough to meet their needs or, more importantly, may not conform to their national standards. The recorded agreement is that "the RI should be developed to modular and rigorous software engineering standards - providing high availability and high message handling throughput and tested thoroughly. If an Access Point derogates from the use of the RI and develops its own IPAP, it does so at its own cost and at its own risk - but it must adhere to the functional and technical specifications of the RI." This means that if a Member State decides to develop its own application to communicate directly with the Coordination Node, it will have to follow strictly the standards to communicate with the Coordination Node that will be documented by the contractor (exactly as for the RI). The aim is to offer Member States a flexible Reference Implementation to motivate them to adopt it. Therefore the Member State committees further decided that the RI must expose some of its key modules to the Member States developers through a plug-in mechanism. With plug-ins, the Member States will have to comply with rules as to where in the sequence of modules and within what parameters they can implement their own specific business. Call for Tender VT/2008/019: Administrative Specifications Page 45 of 101

46 In project management terms, a plug-in is a module with more stringent requirements in terms of the quality of the interface, the documentation and the ability to support Member States who need to develop their own versions. Plug-ins provide for a clean-cut separation of responsibilities between the IPAP and the NPAP. The IPAP is to remain under the Commission's responsibility providing the framework, whereas the other (the plug-ins) is in the hands of the Member States that would actually develop the piece of software. Member States that do so will be only able/allowed to insert that piece of software at the point in the RI that has been predefined and under the conditions that have been predefined in a framework documented by the contractor. The Technical Commission recommended the use of plug-ins. Their purpose is two-fold. Firstly, they allow Member States to implement their own specificities in a clean fashion. It is feared that, in the absence of plug-ins, some Member States will try and modify the standard RI code, leading to unreliable applications which are difficult to maintain Secondly, it is expected that Member States will find it more convenient to stick with the RI if they are given a clean and reliable opportunity for implementing their own specificities. Indeed, some have expressed their intention to use the RI if this will offer the desired reliability and flexibility It will be up to the Commission and the contractor to decide in which areas the plug-ins could be allowed to modify the EESSI RI behaviour via plug-ins; this will come from an assessment of where plug-ins are needed i.e. where this need is expressed by the Member States and where they can be safely allowed. Nevertheless, tenderers that have clearer ideas about this should already indicate in their tender what procedures they would plan for plug-ins and how or in which areas they foresee their applicability. On the basis of the Commission's experience and contacts with the participating country technicians, it is expected that plug-ins would be useful in the areas of database drivers, access control, encryption and data conversions. However, it is too soon to delimit the field of applications of plug-ins and it is expected that the contractor will apply flexibility and accommodate as much as possible the needs of the countries, while ensuring that the system's integrity is preserved. What is called a plug-in in this context is nothing more than an API that defines a clear separation of responsibilities (a contract, in software engineering terms) between the Reference Implementation and any modifications made by the Member States (see Figure 11). Call for Tender VT/2008/019: Administrative Specifications Page 46 of 101

47 Figure 11 Separation of responsibility between the Reference Implementation and National developments within Access Points. The technical implementation for the plug-ins (e.g. dynamic loading, property files, etc.) will be determined as part of the analysis which must take the following aspects into account: abstraction of the data-access layer, enabling Member States to replace the built-in database with the one most commonly in use in their environment (note that this goes further than a database abstraction layer such as JDBC, as it includes the queries as well) cryptographic implementation, enabling Member States to reap the benefits of cryptographic accelerators, should they decide to implement one conversion system, enabling Member States to plug the conversion engine most commonly in use in their environment access control, enabling Member States to integrate the Reference Implementation with their existing user management. Please note that : the above list is not exhaustive, rather only indicative. The exact list will be established as part of the design the plug-ins could take many different forms, for example a data abstraction layer could be implemented as actual code or property files. The most efficient mechanism will be selected during the design phase some of those plug-ins may be offered by the application server, e.g. if using a data framework like Hibernate, it already offers the flexibility needed through proper use of configuration files Call for Tender VT/2008/019: Administrative Specifications Page 47 of 101

48 in this context, the separation of responsibility that plug-ins offer through their API is crucial. They are intended to provide a framework which will give Member States the flexibility to tailor the Reference Implementation to their needs. As well as the development of the plug-in API(s), the contractor will need to provide detailed documentation to enable Member States to make use of this API. It is essential that the RI be developed in such a fashion that its future versions be easily insulated from cross-effects of plug-ins, with a view to having the plug-ins continue to function with new RI releases. For the reasons above, plug-ins are important. As specified below (3.2), much of the EESSI system is expected to be integrated. Several of the off-the-shelf products that can be used to build EESSI offer plug-in frameworks. Because of the plug-ins potential effect on the application's reliability, and the high likelihood that they will be developed by Member States, tenderers and contractors must pay particular attention to the plug-in framework when selecting and proposing to the Commission the products to be integrated Remote update facilities The Reference Implementation will be a sizeable application. It will be maintained over the course of several years and may be deployed in more than a 100 locations across Europe. Over its lifetime, the Reference Implementation may be updated 100s of times (bug fixes, new features, etc.). Maintaining an installation of the software up-to-date is crucial for the proper working of EESSI. However, it is not reasonable to expect administrators on every location to update the software promptly. Hence, the Reference Implementation needs: friendly installation scripts that guide the administration through the installation process; a remote update feature that will be operated from the Coordination Node. It is envisaged that the following characteristics will form part of an automated update feature: when an update is made available, the national (or AP local) administrator of the Reference Implementation is notified (e.g. through the console of the Reference Implementation) and given a chance to download and install the update. when the administrator decides to update its implementation, all the files needed are automatically downloaded and installed, software is restarted, etc. through the appropriate scripts. Minimal human action (apart from confirming the update) is needed. the administrator has a chance to review a description of the update before it is installed (bug fixes, etc.) Essentially, a remote update is foreseen, similar to what is being offered for most operating systems and applications on the market today: RPM (with the update agent), Windows Update, Sparkle, BMC are examples of the broad functionality considered here. It is essential that the updates are performed after approval (and therefore under the supervision) of the local administrator. Likewise the administrator must have access to release notes prior to authorizing the update. Call for Tender VT/2008/019: Administrative Specifications Page 48 of 101

49 The contractor will need to provide the remote update for both the server (installed in the Coordination Node) and the client (embedded in the Reference Implementation) for the remote update Console As in the case of the Coordination Node, an administration console must be available that enables IPAP administrators and other super-users to monitor, administer and configure the various components of the RI. The console must be remotely accessible and preferably web-based. It is expected that different administrators will be assigned to different components of the RI. For example, the local copy directory update may be under the responsibility of some people, the messaging component under the responsibility of other people, while the interface for the clerks under the responsibility of others, some of whom may be also responsible for the messaging component. Each administrator has different responsibility and therefore limited control over the component (e.g. certain sections in the clerk interface, certain routes in the messaging component and the likes). Hence, access to the console must go through the Access Control List (Access Management) and, as already explained, this must have fine grain rights to give users just the rights they need to perform their job The Directory Service As regard to the supplementary functional specification of the EESSI Directory Service, the contractor is expected to address and further detail the following items Hosting As regards hosting the Master Directory, it has been agreed that it shall reside within EESSI in the Coordination node, hence in the Data Centre of the Commission. L1:FS-1 The EESSI directory shall be hosted by the coordination node Managing identity of EESSI participants The functional specifications related to the identity management lists the requirements around the creation and the management of the electronic identity of the organisations participating in EESSI. Requirement to acquire identity L1:FS-2. Any Competent Institution participating in whichever way in the EESSI information exchange shall be listed in the Directory. It is not restricted to electronic exchanges; even Competent Institutions that exchange information with their access points in non-electronic form shall have entries into the Directory L1:FS-3. Access points shall be listed into the Directory Establishment of identity Call for Tender VT/2008/019: Administrative Specifications Page 49 of 101

50 L2:FS-4 Access points: Member States shall fully describe the identities of their access point(s) and submit the information to the coordination node, which shall be responsible for checking the correctness and completeness of information and then inserting it into the Directory. L2:FS-5. Competent Institutions: Member States first shall be responsible for collecting and checking the necessary information; and second to enter it into the Directory. Maintenance of identity L2:FS-6 Access points: The coordination node shall update (or delete where appropriate) the entries. Member States shall provide, when necessary, the pertinent information. L2:FS-7. Competent Institutions: Member States shall be responsible for updating the information on a timely basis Information stored in the Directory As explained above, the information stored in the EESSI Directory service is of three types: 1. Routing information: reference and operational data required for the routing of the SED to the final Competent institution 2. Security information: certificates and keys 3. Administrative information The routing information is twofold: Electronic address and full contact details (e.g. Postal address, phone, fax, etc.) of the entity referenced in the directory (Access Point, Competent Institutions, etc.) Detailed competences (or attributes) of each Competent Institutions (functions, competences of institutions, types of Benefits covered, personal and geographical coverage, etc. The attributes of an Institution constitute the most important information since they will be used by the clerks or the European citizens through the Public Web interface to find the Competent Institution where the SED must be sent. This is the raison d être of the Directory. The Directory should offer the possibility to store the names of the Institutions as well as the addresses in additional different languages chosen by the Member States. In most cases, it will suffice to have the possibility to display the names in two language versions. The main purpose of this facility is to allow Member States whose official languages are based on non- Latin alphabet (e.g. Greek, Cyrillic, etc.) to provide the name and address of their Institution in their national language and to give a Latin version. However, it may also be used by multilingual countries wishing to display the CI names in several languages. Call for Tender VT/2008/019: Administrative Specifications Page 50 of 101 L1:FS-8 The Directory shall store full contact details of the Competent Institutions and access points (e.g. official postal address, telephone, telefax etc.).

51 L1:FS-9 At the technical and implementation levels, the Directory shall be the single and authoritative repository for: o The addressing scheme, addresses and routing information o How services provided by access points and the coordination node are accessed o Digital certificates of the EESSI international domain Storing the attributes of the institutions in the Directory Service As explained above, the main purpose of the EESSI Directory is to facilitate the routing of the SED in providing the routing information of the desired Institution. Each Institution is characterised by its purpose, its sphere of competence, its geographical and personal coverage, etc.. These characteristics are called attributes of the Competent Institution and must be stored in the EESSI Directory like any other information linked to an Institution. (see the list of the attributes in annexe T5). The attributes linked to each institution are uploaded together with the other information related to the Institution. When an institution is inserted into the EESSI Directory by bulk upload or manually through the national interface, the system should verify that some mandatory attributes are present and reject the insertion when they are not present. Since these attributes should appear in the Public Web Interface of the EESSI Directory in the language of the user they have, for the time being, been coded. Since each attribute may appear in any of the 23 official languages of the Union, one possibility is to store directly the code of the attributes, instead of the attribute itself, and use conversion tables to display its name in the desired language. The contractor is free to propose any other solution to store the attributes as long as the multilingual requirement of the Directory is satisfied. If the coding system is used, the code should be an internal mechanism that is shown neither in consultation nor in uploading Accessing the Directory data The purpose of this section is to indicate who will have access to the EESSI Directory and to which level. The Public EESSI Directory (copy of the Master Directory) will have read only access and be accessed through the internet for consultation by the European citizens, the clerks of national institutions, the Access Points and the Coordination node. Only the Access Points and the Coordination Node will have a write access in the Master Directory and each within their own geographical competence. Since each Member State is competent for the information about its national institutions stored in the Master Directory, it should have the right to upload this information into the Master Directory. This facility must be offered to the Member States in their Access Points where an interface will allow each social security sector 29 to either bulk upload list of Institutions or to modify/delete single Institution entries in the Master Directory. 29 The successful tenderer must provide for an access at Access Point level, preferably web-based. It will be left to each country to decide who will be given the duty and required rights to edit the directory. It is expected that countries will create one or more accounts for each social security sector. Call for Tender VT/2008/019: Administrative Specifications Page 51 of 101

52 The Coordination Node should have a full access to the Master Directory for the maintenance of the Directory. Public access L2:FS-10 Information about Competent Institutions can be made available (read-only) to the public, in a form suitable for browsing and searching by citizens. L2:FS-11 If a public view of the Directory is provided, it shall be implemented in a purpose-built application that will draw data from a separate database containing copies of the relevant material listed in specification L1:FS-9, thus completely eliminating the risks associated with providing Internet access to the operational EESSI Directory. Information used for the operational and administrative purposes (e.g. whether a particular Competent Institution has an on-line connection with its corresponding access point) shall not be accessible to the public. Competent Institutions L2:FS-12 Competent Institutions shall have a full, view-only access to the Directory entries of their counterparties and access points. Viewing of technical information (e.g. network addresses of access points) may be withheld from them. Access points L2:FS-13 Access points shall have (i) full, read-only view of the entire Directory contents, (ii) full access rights to all entries concerning the Competent Institutions they are responsible for; may keep local copies of the entire EESSI Directory Coordination node L2:FS-14 The coordination node shall have full access to all entries Responsibility of maintenance As regards the maintenance of the EESSI directory, two types of maintenance should be considered: the maintenance of the content and that of the Directory application. The Access Points will be responsible for the maintenance of the entries of the Directory for the Competent Institutions falling under their responsibility and the Coordination Node will be responsible for the Access Points entries. The Coordination Node will also have the responsibility to maintain the Directory application and take care of the coherence and completeness of the data stored. All modifications of the Directory by the Access Points or the Coordination Node will have to be logged. Call for Tender VT/2008/019: Administrative Specifications Page 52 of 101 L2:FS-15 Access points shall be responsible for maintaining the entries of Competent Institutions falling under their responsibilities L2:FS-16 The coordination node shall be responsible for maintaining the entries of the access points, the EESSI network backbone and the services itself provides

53 L2:FS-17 Access points shall timely submit to the coordination node any change of the entries falling under their responsibility L2:FS-18 All modifications to Directory entries (insert, update, delete) shall be logged Versioning and historical records The situation of a Competent Institution may vary in time. The contact details may change (e.g. address, phone, fax, electronic addresses, etc.) and sometimes institutions may simply disappear, being replaced by or merged with another institution. When processing files, the clerks must have access to that historical information. Therefore the EESSI Directory should keep records of this historical information for several years and be accessible for consultation. L1:FS-19 The Directory shall keep records for Competent Institutions for several years. It shall provide facilities to be able to go back in time and inspect the entries for a Competent Institution Security and accountability The security of the EESSI Directory, its integrity, inviolability should be guaranteed through a serious access control mechanism. Should the system detect any unauthorized action attemps, it should reject it and log the attempt on the Directory. L2:FS-20 Prior to accessing the Directory for the purposes of modifying entries, users shall be identified and authenticated L2:FS-21 Prior to any attempt for a modification of an entry, the user s authorisation to perform this action will be checked. Any unauthorised action shall be rejected and logged Provisioning of search applications In addition to the application for uploading and maintaining records into the Master EESSI Directory, described above, the EESSI Directory will need an application to search entries in the Public EESSI Directory. The public application for searching entries in the Public EESSI Directory should be a Web application available on the Internet for the clerks as well as the general public. Since it will be publicly available, the interface must be compatible with W3C recommendations and all the major browsers (notably including Internet Explorer 6 and above, Firefox, Safari and Opera) and IPG compliant (see The interface should be multi-lingual, simple and user-friendly and with the possibility for the visitors to make at least three different types of search: Free Text search, Search an Institution on attributes, Browse for a Search Engine Optimisation 1. Free-text Search Call for Tender VT/2008/019: Administrative Specifications Page 53 of 101

54 Search has emerged as a UI paradigm in last decade. In many cases, when confronted with a unfamiliar task, it is easier for users to search using a free-form text (à la Google) rather than clicking through menus and options. It is expected that the primary interface of the interface will be a multilingual search engine, customized for the content of the Directory. It is not expected that this will require a very sophisticated search language (e.g., one that allows + and - expressions) although it would not hurt to have that option. It is expected that guidance in the sense of search terms will be needed. Obviously search must be multilingual, allowing citizen to name countries, sectors, etc. in any language. Therefore the search engine must accept synonyms (e.g. the citizen searching for illness or clinique instead of sickness must be given a useful answer). The interface should also allow visitors to provide partial information (e.g. the name of the institution, an address, etc ). Note that many searches are expected to be on Institutions delivering EHIC and the engine should give them special priority. 2. Search an institution on attributes This part of the application should offer the possibility to select some criteria for the query among a structured list of available attributes (e.g. looking for an institution in Germany, whose function is Competent Institution, the category of Benefit is Sickness, the type of benefit is Benefits in cash, etc.). The result of the search may be one single Institution or a list of several Institutions depending on the attributes provided by the visitors. Figure 12 shows what the search frame could look like. Figure 12: Example of Web Interface for the Directory Service This interface is primarily intended to offer guidance to the clerks. Note that an elegant solution would be to build this interface over the free-text search, e.g. if the clerk selects Benefit in Kind it is passed as type: Benefit in Kind to the free-text search. 3. Browse for SEO (Search-Engine Optimization) The last option must be a browse solution that allows visitors and, most importantly, search engines, to navigate through the entire database. Call for Tender VT/2008/019: Administrative Specifications Page 54 of 101

55 The browse is offered primarily as a SEO alternative to the built-in search. Indeed most citizens looking for the information in the CLD will turn to their search engine of choice (with which they are familiar) and not to the EESSI Directory. Obviously since search engines cannot index data beyond the search forms described in the first two sections, an alternative access must be provided. Since it is intended primarily for SEO, this version must be friendly to crawlers, by making good use of HTML tagging, having descriptive titles, search engine friendly URLs (no parameters in a query string) and use other SEO techniques, as appropriate. Again it will use synonyms to provide a good selection of multi-lingual keywords to the crawlers ( Germany, Deutschland, Allemagne, etc.). Needless to say that the browse version of the Directory must comply with the search engines rules for content. So when SEO is mentioned in this document, it must be read as the so-called white hat SEO. The contractor will also take the appropriate steps to make sure the browse option is being indexed properly (submission to search engines, if needed, sitemap, and the like). L1:FS-22 A special application shall be developed for searching and viewing directory entries L2:FS-23 User-friendly applications shall be developed for: o Maintenance of entries by access points (e.g. responsibility for entries of a Member State sector) o Bulk uploading and downloading entries (e.g. Competent Institution directory tree for a Member State) Directory architecture It is expected that there will be the need to store additional data in the Directory, not originally included in the specifications. The design of the directory architecture should allow the addition of additional entries without major changes. L2:FS-24 The design of the EESSI Directory should anticipate a growth in the number of roles and attributes for inclusion in the Directory. This may call for a federated or tiered directory design rather than a single, monolithic directory server located in the coordinating node. L2:FS-25 In case access points maintain local copies of the EESSI directory, one-way replication of directory content between the coordination node; the access point in question shall be automatic in the sense that it shall not require human intervention The addressing scheme issue A good addressing scheme is a prerequisite for the efficient and smooth operation of EESSI. The organisational complexity of Social Security in the Member States and the great amount of Competent Institutions (more than currently in the CLD for the sickness sector alone) makes the design of an appropriate addressing scheme a non-trivial task. Call for Tender VT/2008/019: Administrative Specifications Page 55 of 101

56 The feasibility study has proposed that a hierarchical addressing scheme be employed in EESSI for routing and dispatching of SED to their recipients. One candidate addressing scheme is a four-level one implemented as follows: Level 1: Country Level 2: Competent Institution Level 3: Regional office Level 4: Additional addressing information, at the discretion of the Competent Institution The first 3 addressing levels are depicted in Figure 13. Level 1 address Level 2 address Level 3 address Access point Competent Institution Regional office Figure 13: Hierarchical addressing scheme Other hierarchical addressing schemes are possible like level 1: country; level 2: function; level 3: competence and may be proposed by the Contractor. L2:FS-41 A hierarchical addressing scheme shall be implemented, uniquely identifying message originators and recipients. L2:FS-42 The addressing scheme shall have two parts, an international one and a national one. The international one concerns the message transfer between the access points, while the national one the message transfer between the Competent Institution and the access point. L1:FS-43 The addressing scheme shall have no dependencies on the message payload. L1:FS-44 The addressing scheme shall define how the message is routed in the EESSI international domain (i.e. whether it will be routed through the coordination node) The replication mechanism and protocols As explained above and illustrated in Figure 6, the EESSI Master Directory hosted by the Coordination Node will not be accessible in consultation from the public. Instead, it should be regularly replicated in each local Access Point as well as on publicly-accessible web interface hosted in the European Commission Data Centre. Call for Tender VT/2008/019: Administrative Specifications Page 56 of 101

57 The local copies in the Access Point will be used by national applications. EESSI s responsibility is limited to ensuring replication of the Master Directory to the Access Points willing to have a local copy of the Master Directory for national purposes. The copy in the Data Centre is the EESSI Public Directory is a copy (or a partial replication) of the Master EESSI Directory that will be accessible by the public on Internet via a dedicated interface developed by the contracted party. It should be noted that the general public will not have a total view of all information stored in the directory, rather only a partial view. Only information on the Competent Institutions will be accessible through this public access. So it could be imagined that two kinds of replication may be considered as necessary for EESSI: bulk replication of entries of the Master Directory for the Access Point and selected replication for the EESSI Public Directory. Another solution may consist in limiting the types of access to the public web Interface. For the Directory, the replication protocols, etc. it is expected that the contractor should propose proven standardised technologies and products The Security in EESSI The needs There are two main assets in EESSI whose security must be ensured, the SED messages (and their annexes) and the outstanding parts, including the Directory entries. Generally speaking, SED messages require higher protection than the other data. These often contain personal data on individual claimants and should only be read by the clerks who process their claims. In other words, in addition to integrity, there is here a confidentiality requirement. The outstanding information in EESSI, namely the Directory and the information repository, requires integrity but not confidentiality. While it is still important that write-access be restricted and logged and the information's integrity is very important, the information is generally made available to the public (e.g. the public web access to the Directory). Hence, there is no confidentiality requirement (apart from the Access Control information, which must be fully protected). The level of confidentiality of the SED message data is "not classified". However, the data will often contain sensitive information on individual people, such as their employment and health situation. This means that it must be protected rigorously. The integrity of EESSI directory entries and the flow, message and data descriptions is paramount. SED messages will be built on the basis of this information and, if this were not correct, the wrong messages might be sent to the wrong address. This would not only disrupt the EESSI business until the data is corrected (e.g., when a SED is mal-composed and does not contain the required information), but also possibly cause leaks of sensitive information (e.g., when the SED messages are sent to wrong recipients). More fundamental still is the integrity of the access control information. It is important that directory entries be editable only by those who are allowed and trained to do so, via access control. The risk is that entries by unauthorised persons cause sensitive information to be sent to a wrong address. Call for Tender VT/2008/019: Administrative Specifications Page 57 of 101

58 The data must be validated. Completeness, compliance and consistency checks are to be applied to SED messages, directory entry inputs and parts of the document repository. At the tendering stage, the checks to be applied are not yet defined Envisaged security Some security features were discussed during the development of the feasibility study and there was a consensus from Member States around the following 1. The EESSI exchange will be carried out over the stesta network. This means that, from the moment a message enters the stesta national domain of the sending country until it leaves the stesta national domain in the receiving country there will be network-level security. 2. From the Access Point (AP) of the sending country to the Co-ordination Node (and then from the Co-ordination Node to the AP of the receiving country) the messages will travel under SSL. 3. In addition, the message body (all except the message envelope which must be read by the CN for routing, monitoring, logging and statistics) will be encrypted "endto-end" from the origin AP (or CI) to the destination AP (or CI 30 ). 4. Any communication from AP to CN other than messages will travel under SSL with a view to preserving its integrity. 5. As specified above, the Master Directory will not be accessed directly from the internet; the MD will be replicated into a copy that will be accessible from the internet. This is illustrated in the diagram below Data Exchange diagram Figure 14 may help identify the security issues in the planned EESSI system. 30 Once again, while it is expected that most or all countries at the start of the EESSI system production will adopt the RI, later some may develop their own IPAP implementations. Call for Tender VT/2008/019: Administrative Specifications Page 58 of 101

59 Figure 14 Data Exchange Diagram This figure should be read jointly with figures 1 and 2 that illustrate multi-country exchange. In figure 14 only one country is indicated to reduce clutter.the exchanges in Figure 14 are denoted by arrows. SED messages SED messages and their enclosures are prepared by Competent Institutions (bottom left, plus occasionally the PMO 31 on the right). They consist of envelope and body. The body is encrypted with the destination CI key from the origin. To prepare and encrypt the messages, CIs can use either the web-interface for the clerks, in the IPAP-RI, or their own national applications interfacing through the NPAP. They will also receive messages from foreign CIs via these two interfaces. At the IPAP messages are SSL-encrypted using the CN key and sent to the CN for forwarding, via the stesta network. The IPAP could be within the national stesta network or connected to it. At the CN, message envelopes are SSL-decrypted for statistics, monitoring and logging and, most important, forwarding. The last action requires encrypting the whole message with the destination CI's key. Other communication The Master Directory (MD) and the Information Repository (IR) will be maintained by the European Commission and the Access Point managers. All accesses must travel via SSL. The 31 The PMO, or Pay-Master's Office, is an office within the European Commission. It will participate in the coordination of social security in Europe and hence will have to exchange SED messages with national Competent Institutions. As such, it will act as a CI itself and have its own Access Point. It is expected that it will exchange messages infrequently and that it will make use of the web-interface for the clerks in the RI. Call for Tender VT/2008/019: Administrative Specifications Page 59 of 101

60 Commission, in addition to its snet access to the Data Centre, which hosts the MD and IR, will have access via a dial-up access that goes through the stesta network 32. The public Directory view will be a one-way copy of contents from the Master Directory to a web page that allows outsiders to view its contents. This page will be still at the data centre but on the internet. Once the contract starts, the contractor must pay particular attention to the interfaces at the edges of stesta, in particular between the IPAP and the NPAP, and between the Master and the copy directory. The contractor has to study the security risks associated with the communication between these components and propose solutions that are to be submitted to the Commission for approval General guidelines for solutions It is important that the security be built into the software and since it is expected that the EESSI will consist as far as possible of integrated software, security aspects are an important aspect in the choice of the software to be integrated. All outstanding software, to be developed by the contractor, must be designed for security and include the necessary security mechanisms, such as access control. For this, and in as much as software is developed, it is important that the contractor's software development staff be trained on critical software security issues. Shortly after the start of the contract, the contractor is to deliver a risk plan, as indicated in the Administrative Specifications (see section 8), as part of the final and complete set of Functional Specifications. This must also include a security plan, which in turn should include a security risk analysis and a security test plan. The analysis must be accompanied by proposals for risk treatment, i.e., a choice of security countermeasures to mitigate detected risks to protect assets, according to their security needs). The last item will be included in the security plan. At the end of the contract, the final report must include a list of residual security risks for the Commission to accept. The contractor should pay special attention to the requested provisions concerning encryption (see ) and those concerning security in the Access Points (see ) SED Message security As regards SED message security, several Functional Specifications were approved by the relevant committee and are presented hereafter. Trust For secure exchange of data over a network, the sending and receiving nodes need to trust one another. Typically, this is achieved with the establishment of peer-to-peer and hierarchical trust relationships between communicating nodes. Since in EESSI data transfer will take place over a trusted, close network, trust between the access points is already in place. L1:FS-64 The security provisions and the architecture of the underlying data exchange network shall provide the basis for the trust between access points 32 It must be clear that, while in Figure 14 both the Commission and the IPAPs connect to the stesta central domain and system, it is not to communicate with each other. Both use it to communicate with the Co-ordination Node. Call for Tender VT/2008/019: Administrative Specifications Page 60 of 101

61 Confidentiality It is important that the confidentiality of the messages in transit over the EESSI network, and at rest, be secured. Typically, the confidentiality of the messages is secured with encryption. A typical implementation scenario is when the EMS encrypts the contents of the messages exchanged between access points. L1:FS Access points shall provide encryption facilities at the message exchange level; those may be used in cases higher layers of the access point services have not encrypted the contents of the message. Integrity L1:FS-66 The EMS shall protect the integrity of messages in transit and at rest; it shall provide the means to verify the integrity of a message. Non-repudiation of message origin The EMS may provide functionality to provide, if necessary, evidence of the message origin, and bind the contents of a message with the originator (e.g., using a digital signature). L2:FS-67 The EMS may provide functionality to provide evidence for the non-repudiation of messages. Identification and authentication In addition to access points trusting each other, it may be desirable to identify and authenticate each other. Access points should support standards based identification and authentication methods. The identification and authentication should be independent of the data transport protocols, and should be a replaceable (through plug-ins, see ) component of the access point service. L1:FS-68 Access points shall provide functionality such that they identify and authorise each other. Digital certificates may be used for such purposes Transport level security L1:FS-69 Access points shall provide network transport level encryption (e.g., SSL, HTTPS). Logging of activity L1:FS-70 All information exchange transactions shall be logged for future reference Access control Several components of the EESSI system can be accessed for action. These include the Master Directory, the information repository, the web-interface for the clerk, other parts of the RI. They must be protected by Access Control mechanisms, as specified in the relevant sections above. 33 Please note that the Technical and Administrative Commissions have agreed on the mandatory automatic use of Web-Services security between Access Points this means that all messages will be automatically encrypted from Access Point to Access Point (see Annex A3, page 17) Call for Tender VT/2008/019: Administrative Specifications Page 61 of 101

62 The Gateway service The Coordination Node may act as a proxy for Access Points given that, in the EESSI architecture, they do not establish direct communications with their counterparties. The figure below illustrates this principle; Access Point 2 provides a service (e.g. verifying that a SED was routed to a Competent Institution) through a Web service interface, but makes this service available only to the Coordination Node. In other words, Access Point 2 does not wish to provide this service directly to counterparty Access Points. A justification for such an arrangement may be that Access Point 2 does not wish to undertake the task of validating counterparty Access Points (e.g. perform authentication). When Access Point 1 wishes to invoke the services of Access Point 2, it makes a request to the Coordination Node, which in turn checks that Access Point 1 is authorised to invoke the particular service of Access Point 2. It then invokes the service of Access Point 2 on behalf of Access Point 1, obtains the result from Access Point 2 and returns them to Access Point 1. Web service client Web service front-end Web service client Web service front-end Access point 1 Coordination node Access point 2 Figure 15 : Gateway services of EESSI L2:FS-76 The coordinating node may provide gateway services to other access points L2:FS-77 The coordinating node shall implement the security functional specifications laid down for access points Scalability and failover The EESSI system must be scaleable and the scalability must arise from the scalability of every component: the Coordination Node, including Directory service, repository, messaging service, web interface for clerks and the other services as specified above, the public access to the directory and the Reference Implementation. Specifically the challenge is threefold: it is expected that the deployment of EESSI will occur gradually. Not every Member States will be in a position to join the exchange from day 1 and it is likely that some Member States will negotiate transitional periods (essentially delays before joining the network). Therefore traffic will grow over time; it is expected that the needs for EESSI will also grow over time. It is envisaged that every year more Europeans travel in Europe and settle in other countries for pleasure or business. The social security coordination could be extended to additional countries. Therefore the volume of exchanges is expected to grow over time; last but not least, the exchanges are not evenly spread across Europe. Every country has a number of partners with which it exchanges more often, for example because of geographical proximity. In addition, some countries exchange more than others Call for Tender VT/2008/019: Administrative Specifications Page 62 of 101

63 because they have a larger population or because of other factors. Therefore some roads in the network will experience more traffic than others. Consequently, the various components must be capable of growing from small traffic (expected in the first few months of operation) to much more significant traffic over time (see annexe T3 for long-term traffic estimates). Scalability is therefore a design and development characteristic. Various strategies exist to enable scalability, from load-balancing to clustering and the contractor is to choose the most economical solution and validate the scalability of its components. Finally, although not directly related to scalability, failover must be made possible. The Coordination Node will be a crucial hub and the design and implementation must take this into account. For asynchronous traffic, down-times of up to one day are acceptable but for synchronous traffic, reliability must meet or exceed 99% availability. Therefore the various components of EESSI that are in the critical communication path (directory, messaging service, reference implementation and others) must be capable of failover The EESSI system's minimum requirements The contractor will need to test specifically for scalability and failover. The system's minimum requirements are as follows: 1. The Coordination Node must be able to handle 15,000 messages per hours in peak time or, at least, the architecture must be scaleable enough to be able to handle those 15,000 messages per hours if needed. 2. The Coordination Node must be able to store at least 250,000 messages in queues in case these cannot be delivered immediately. A message may reside in the queue for up to a month before being delivered. This assumes that the coordination node must store messages in case the recipient is temporarily unavailable. 3. The Coordination Node must be able to perform a fail-over within 30 minutes and without loosing any message. 4. The Directory must have a response time of less than 1 second and must be able to handle 300 requests per hour in peak time 5. The Coordination Node must be designed in such a way that its up time is at least 99% 6. Assuming both Access Points are operational, the typical asynchronous message (size up to 5 Kbytes) must be delivered from AP to AP through CN in an average time of less than 10 seconds; As regards other system components (including support, training, documentation) no minimal requirements are expressed here. However, the contractor is to deliver them in the respect of industry quality standards with, as a minimum, the quality standards that they themselves will have specified in their tenders. Call for Tender VT/2008/019: Administrative Specifications Page 63 of 101

64 3.2. Framework for a solution Introduction In the previous sections, the EESSI environment, the general architecture, the requirements, the functional specifications were described, and below there are descriptions of the requirements concerning the testing (see 3.4), the operations and the maintenance. By now readers should have a good understanding of EESSI as a project and should begin to understand the role that the contractor is expected to play. In this section, attention is turned to the work of the tenderers and contractor by describing the vision for the EESSI project development. The purpose of this section is twofold: define a framework for the writing of the tender. Since the vision of the work to be performed by the contractor is articulated, it is expected that the tenders should be written against this vision. In other words, tenderers should describe their planned work by referring to the subsections in this section. clarify what is expected to be built against what should be integrated. In fact, the project is under a firm schedule and must deliver a very high quality system. In other words, to achieve this, it is expected that the contractor will integrate existing 34 (tested and debugged) software as much as possible, rather than develop new systems from scratch. The Commission is aware that significant portions of the architecture already exist and it is expected that the contractor integrate (a choice among) them aggressively and develop new software only where it adds value or is necessary; in any case, the choice of developing any of the software part must be motivated. In addition, the Commission expects that the contractor shall build on standard frameworks as much as possible. Please note that the order of the subsections below is not significant in terms of the project execution. In fact, it is expected that most of these tasks will take place in parallel. Once again, any components of RI should be chosen so that it carries no licence costs. This is because the Commission has pledged to provide the RI to participating countries and cannot make them pay for it The Coordination Node Most of this section concerns components of the Reference Implementation, which implements the International Part of the Access Points. As noted above, the other main component of the EESSI system is the Coordination Node. The Coordination Node is to be installed at the Data Centre. Hence, it has to comply with the guidelines of the Data Centre 35 ; on the other hand, it is free from the no-cost requirements that apply to the Access Point s RI; nevertheless, the contractor must choose the most appropriate products to implement it and, in the choice of the products, licence costs should be taken into consideration. 34 The software to be integrated may be under any type of licence; however, tenderers (and the successful tenderer during the contract period) must bear in mind that the EESSI Reference Implementation is to be free of licencing charges for the countries that choose to install it. 35 As regards the requirements for applications to run on the European Commission s Data Centre, please consult annexe T4; Call for Tender VT/2008/019: Administrative Specifications Page 64 of 101

65 As a general principle, the need to integrate existing products as much as possible applies to the CN as well as the RI. The Coordination Node is multi-faceted and consists of several components in addition to the Messaging Services; for each component, there can be existing products that implement them. The contractor will be requested to provide a justified choice and submit it for approval by the Commission. Tenderers should indicate either existing products that they envisage to integrate, if any, or a methodology that they plan to apply in selecting the right products. As with any such IT project, tenderers need to show that they are able to guage what is available on the market and evaluate it with a view to building the various components of the CN Application Server Selection The Reference Implementation builds on an application server. Consider Figure 16 and Figure 17 which are respectively a high-level view of the Reference Implementation and a zoom-in into the web service stack. Most of the services presented in these figures are available through off-the-shelf application servers and the many accompanying libraries and frameworks. Examples of application servers include JBoss, Geronimo, Jonas or GlassFish. Examples of libraries and frameworks that could be considered include Axis (for Web Service), Spring, Azuki, mootools, Prototype, jquery and script.aculo.us and many others. Note that, although the above list is made up exclusively of Java and AJAX libraries and frameworks, alternatives in other languages/other platforms (e.g. Rail, Flex 3) are perfectly adequate. One of the tasks for the contractor will be to select, package and integrate those components. It is preferred that the development effort be limited to those portions where the added value is maximum, while relying as much as possible on standard, well-tested and proven packages where possible. Obviously, although most of the Reference Implementation can be found in existing packages, some portions are more specific to the project, such as the human-assisted routing front-end or the web interface and may require some development. Call for Tender VT/2008/019: Administrative Specifications Page 65 of 101

66 Competent Institution National Network National portal Portal database XML conversions LDAP Directory server Directory store Access point national part File system Database Web services JMS EJB Input- output queues EMS Encryption/ Decryption Message Transport Agent MTA MTA store Input/ output queues International message transport module SED validation File packaging Interface with national on-line systems EESSI International Network EMS Store Human-assisted routing front-end Clerk Security Monitoring and logging Web services interface JMS interface Figure 16 : Reference implementation high-level view EJB interface Other to-be-defined interface WS-Reliable Messaging WS-Addressing WS-Eventing (optional) WS-Security Message exchange WSDL Description SOAP XML encoding HTTP Messaging Transport Figure 17: Web services stack The contractor will need to factor in what is available on the market to determine the most appropriate application server, library and framework. The list of characteristics will be decided with the European Commission once the tender is awarded as part of the project but it is expected the following ones will rate highly (this is not an exhaustive list): Call for Tender VT/2008/019: Administrative Specifications Page 66 of 101

67 suitability to meet the project requirements vitality and size of the community supporting the project quality of the product, quality of support experience of the contractor with the product experience of the Member States with the product experience of the European Commission with the product respect of industry or formal standards amount of customization or custom development needed for the project quality and ease of use of the conversion components (see below), including the quality of the user interface for the development and maintenance of conversion mappings ease of deployment and installation at the Access Points The conclusion of the analysis will be the choice of one product in each category and established detailed specifications on the extent of the integration and development efforts needed with the selected products. The tenderers must explain: how they arrived at their choice detailing the pros and cons of different application servers, libraries and frameworks, at the level appropriate for making this choice. the rationale of the product selection. To demonstrate these, the tenderers can use any appropriate means in the tender they see fit.. Overall, where the tenderer has clear ideas and wishes to recommend certain products, positive evidence demonstrating why such a choice has been made or negative evidence why another product has not been chosen should be attached to the tender. Overall, where the tenderer has clear ideas and wishes to recommend certain products, positive evidence demonstrating why such a selection has been made or negative evidence why another product has not been selected should be attached to the tender Web Service Stack Choice The indications of the previous section on the application server apply here too Directory Server Choice On the surface, the choice of the directory server is very similar to the choice of the application server and the web service stack. Indeed the goal is to select the most appropriate tool under the constraints of the project and a lot of the indications above apply here too. Since the directory server is an LDAP server, some development or customization might be needed for the integration with the web interface or the web access (replacement of the CLD). However the context of the selection will be slightly different: the Master Directory will be deployed in the Data Centre of European Commission and must be accessible, for replication, to the Access Points the Access Points will replicate the Master Directory Call for Tender VT/2008/019: Administrative Specifications Page 67 of 101

68 a copy of the Directory will be made available to the public through an intuitive webbased interface on the Europa web site. Most likely, given the stringent security constraints on stesta, this will require another copy of the Directory. Due to the same security constraints, that copy will need to be disconnected from the Master and synchronized through secure means the interface to the Directory is specified as the LDAP protocol so it is conceivable that different LDAP implementations be used in different points of the network, each optimized with different parameters. Alternatively, if suitable, one implementation may fit all the requirements. the data in the Directory (the list of institutions) will be maintained by the Member States so they need efficient mechanisms to load updates in bulk and individually. Since the Directory must be operational before the Access Points are implemented and since not every Member State will install their Access Points promptly (depending on the migration/transitional periods), a user-friendly UI accessible on the major platforms (Windows, MacOS, Linux, FreeBSD) will be needed. This could well be web-based; since the purpose of this interface will be to modify data, this should be separated from the public access "web interface" there are multi-lingual requirements, as indicated above The contractor will look to see what the market has to offer whose outcome will be similar to the application server and web services analysis (see 3.2.3) but taking into account the specificities of the Directory service Application update client and server In addition to scheduled iterations, there may be the need for exceptional updates to deal with urgent requests and important bug fixes. For both scheduled and exceptional updates, there is a need for setting up a framework. This should be supported by applications for maintaining and structuring updates at central level (probably the CN) as well as applications on the client (AP) side that can query the CN, check their update status and, if needed, proceed with download and installation. The contractor has to study the need and propose an update procedure. As regards update applications, it is likely that there are ready-made products that fit the EESSI project needs. Within these it is important that the client application be chosen so that participating countries do not incur additional licence costs. Once again, the contractor will need to factor in what is available on the market to determine the most appropriate application update client and server whose outcome will be similar to the applications above Messaging Protocol Specification As explained in the first sections, the feasibility study has established that the messaging between the Access Points and the Coordination Node will be using SOAP and WS-Security (securing this portion of the exchange is mandatory). It has also been decided that all communications must take place through the Coordination Node. Access Points cannot communicate directly with each other. Obviously that leaves many options open and many decisions to be made. Just to name a few (and, of course, any combination of the following): Call for Tender VT/2008/019: Administrative Specifications Page 68 of 101

69 RPC or literal use of encoding style choice of transaction style: messaging-oriented transactions (send to, read message),workflow-oriented transactions (reply/response pattern, unicast pattern, etc.) or business-oriented transactions (specific requests for every sector of social security) role of the Coordination Node: validation, routing, special consideration on WS-Security to offer Access Point to Access Point security possible use of extensions beyond WS-Security The role of the Coordination Node needs further clarification for two main reasons. On one hand, the feasibility study introduced it to simplify communication and, in particular, its testing, upgrade and maintenance - between Access Points by conveying all the exchanges through it, therefore hiding the complexity of the network. On the other hand, WS-Security impacts this: to hide the complexity, the Coordination Node needs to use its own certificates, decode and re-encode the messages for the target Access Point which would defeat the purposes of Access Point to Access Point security. The contractor will need to narrow this set of needs down to a manageable protocol for messaging between Access Points, see Figure 18 for examples of possible protocols. Technical protocol 1 Technical protocol 2 Access point A Access point B Access point X Coordination node Access point Y Invoke service of access point B <&> Prepare response Dispatch message <=> <+> Notify reception of message <#> Dispatch response Store message in temporary message store <=> Dispatch message Notify about dispatch to access point Y <+> <=> Notify reception of message Call for Tender VT/2008/019: Administrative Specifications Page 69 of 101 Figure 18: Example of a protocol Of special consideration is the fact that Member States can either use the Reference Implementation to setup their Access Points or build their own. Therefore the contractor must ensure interoperability between all of these modules and this can only be done through detailed and clear protocol specifications. Such specifications will be an essential deliverable so the collaboration of technicians and technical writers is required to deliver the level of quality needed. Finally, specifications are only as good as the validation and testing procedures that support them. It is expected that the contractor will deliver a test suite to validate the operation of the

70 Reference Implementation but also Member States' implementations against the specifications. Some of the tests should be lifted from standard Web Service testing suites but some tests will be specific to the EESSI protocol. One of the first tasks of the contractor will therefore be to create the specifications for the messaging protocol, to provide ample documentation (both in a formal language like WSDL and in technical English) and a test suite. The Reference Implementation will be one of the implementations of the messaging protocol. The tender should indicate how designing and documenting messaging protocols over a Web Service stack, with the technical specifications chosen (e.g. SOAP, WS-Security and WS- Addressing) and copywriting will be undertaken SED and Business Protocol Design As covered in the section on protocol document below, the business protocol (including flow specifications and SEDs) is documented in a model with a goal to extract the technical implementations from the models automatically. Ultimately, the goal is to enable the flexibility needed to maintain the protocols in a changing environment. There are three tasks in relation to this work and the tender should indicate how modelling and exploitation of models automatically and building the tools to extract such information from a model will be undertaken: to develop stable, user-friendly SED and business flows modelling tools over the existing infrastructure made of Poseidon for UML and a set of XSLT stylesheets to assist in the modelling of the results from the Ad-Hoc Groups by participating in a number of workshops with the Commission technicians who produce the UML version of data and flows 36 to design the Coordination Node and Access Point in such a way that the business protocol can be updated and modified through configuration files and other documentations (WSDL, XML Schema) that will be produced by the SED and business flows modelling tools Common Conversion Services Development The feasibility study foresaw that some of the conversion services and message building services will be available as standard components of an application server and/or web service toolkit, and will be a factor in the choice of a package. In practice, the quality of this component is essential for integration of the solution by some Member States. If however for some reason, the package chosen was found lacking, it is expected that either a more efficient package be integrated or portions found lacking developed as part of the integration of the Reference Implementation. So far the conversion functionality has been covered as a basic tool. As stated, it is expected that this effort will be primarily an integration effort. 36 To be held in Brussels (see 4.9) Call for Tender VT/2008/019: Administrative Specifications Page 70 of 101

71 On top of this tool, conversion mappings will be developed, mostly by the Member States as part of their installation of the Reference Implementation in their Access Points. However there are opportunities to reuse some of the conversion mappings, more specifically: in the EESSI community, a significant percentage of Member States store their records on mainframes and/or use applications from which it is easy to extract fixed position documents (often called flat files). For historical reasons, those files are known in EESSI as MTF files (Magnetic Tape Format). It is expected that the Reference Implementation will be able to convert from flat files (MTF files) into EESSI transactions. Note that not all Member States use flat files, and those which don t will probably develop their own mappings using the conversion engine. Furthermore, a number of conversion routines (conversion of code lists, conversion of date formats and other conversions to support legacy formats) will be common to many Member States and many mappings. Those common conversion routines should be provided as part of the Reference Implementation. In addition, the contractor should make available a framework for Member States to introduce their mappings, an operation that many Member States will be carrying out after the end of the EESSI contract. By providing common routines, Member States which develop their own mappings can still reuse as much common work as possible. Last but not least, if and when different versions of the EESSI SED protocols are introduced, it will be necessary to offer conversion services at least during migration periods. Obviously, the last three points are so specific to the project that they will probably require extensive development, excellent testing and quality management. By their very nature, i.e. since conversions perform what is inherently an error-prone service, they require extensive testing and validation Messaging Service Integration In EESSI, the messaging service will be built on Web Services and, more specifically, SOAP and WS-Security. It will also depend on a Coordination Node that will act as central router between the Access Points (communication between the Access Points is never direct but always occurs through the Coordination Node), see Figure Coordination node 3 Access point A <#> <#> Message relay <#> 2 <=> <=> 4 Access point B 7 <=> Access point A sends message to message relay of coordination node 2. Message relay dispatches message immediately to access point B 3. Access point B receives incoming message 4. Access point B prepares its response 5. Access point B dispatches to message relay its response message 6. Message relay dispatches message immediately to access point A 7. Access point A receives reply message of access point B Figure 19 : Message relay through the Coordination Node Call for Tender VT/2008/019: Administrative Specifications Page 71 of 101

72 As explained in sub-section 3.2.2, it is expected that the bulk of the Message Service will be provided through a web service stack. The standard web service stack will be configured to implement the protocols defined as part of the Message Protocol Specification (see above). As covered in the requirements section and illustrated in Figure 20, Member States will have a choice of interfaces into the Messaging Service: files, JMS, database, web services, etc. Competent Institution National Network National portal Portal database XML conversions LDAP Directory server Directory store Access point national part File system Database Web services JMS EJB Input- output queues EMS Encryption/ Decryption Message Transport Agent MTA MTA store Input/ output queues International message transport module SED validation File packaging Interface with national on-line systems EESSI International Network EMS Store Human-assisted routing front-end Clerk Security Monitoring and logging Web services interface Figure 20 : Reference implementation overview JMS interface EJB interface Other to-be-defined interface So it is expected that the Messaging Service will require extensive integration work in both the Reference Implementation and at the Coordination Node and limited custom development. Most importantly, it is expected that testing and validation of the Messaging Service will be thorough, since it is one of the most central components in EESSI: if messaging doesn t work, the EESSI system fails Directory Service Development and Integration Like most services in EESSI, it is expected that the Directory service will rely heavily on existing products. However, as outlined in the Directory Server Selection, it is expected that: integration and possibly development efforts will be needed to setup the Directory at the Coordination Node Call for Tender VT/2008/019: Administrative Specifications Page 72 of 101

73 integration efforts are needed to support the Directory service in the Reference Implementation integration and development effort are needed to propose an easy-to-use web access to the Directory service. It is expected that some effort will be needed to interface the web access with the Master Directory, in view of the security requirements on stesta. For the Coordination Node and the Reference Implementations, we expect that very little effort will be needed. The directories in the Access Points are just replications of the Master Directory at the Coordination Node. The web interface is different because: it is a citizen-oriented service which may be used infrequently (people may use it to look up this data a few times during their working or non active lives (e.g. around the time they retire) so it must be very polished and intuitive; stesta places security constraints on information that is available both on the secured network and the Internet. It is expected that some effort will be needed to enable proper data replication in view of its security requirements; it must offer different UI paradigms: a search box that allows the citizen to enter informal queries and obtain meaningful results (e.g. search on blessure allemagne even though the official wording was sickness germany ), a browse-mode that can be crawled by search engines (i.e. special care not to use parameters in URLs, robot protocol, etc.) and a wizard-like system for citizens who need guidance. Integrating and deploying directory services in web interface design and development (including white hat SEO), in using search as a UI paradigm and in security considerations is important Web UI Development There are three main blocks in the Reference Implementation, two of which have already been covered so far: messaging service directory service web interface for social security clerks This section outlines the web interface. One of the challenges of social security in an international context is that the migration flows vary greatly among Member States. Some have flows that are large enough to justify investing heavily in the IT processes, others have more limited flows and cannot justify the same level of investment. Some Member States have huge flows during the vacation periods when people cross borders, but limited flows of workers, and, as a consequence, for them, investments in health care makes more sense than investment in pensions. The web interface for the clerk aims to offer a basic level of service that is available for every Member State. It should offer a data-entry and message application that allows clerks to manage the electronic exchanges they are part of: receive electronic messages from other Member States, prepare replies, send queries, etc. In essence, it s a webmail but for structured Call for Tender VT/2008/019: Administrative Specifications Page 73 of 101

74 documents instead of free-form s. Moreover, the structure of the documents varies within a large array of schemes, each suitable for a specific situation. Since, by definition, clerks using the web-based application do so for sectors where migration flows are sporadic, they will not be fully trained and will develop little experience in using the application. Hence, this must be very user-friendly SED Form Engine and Workflow Selection While on the subject of the Web Interface for clerks, it is worth paying attention to the underlying engine. As stated earlier, given the number of SEDs and their expected evolution, it is not acceptable to hard-code a set of SED computer forms. Instead, the Web Interface for clerks must be built over a flexible SED form engine or a workflow system. The said engine must be integrated with the Reference Implementation on the one hand and with the UML models on the other hand. Because of the number and complexity of the required SEDs, it will probably not be possible, time-wise, to design every SED form by hand. The process will have to be automated to a certain extent and the suitability for automation is an important aspect in selecting the best tool Help Desk Setup The contractor will need to setup a help desk and empower the help desk with the tools to manage and monitor EESSI. Said tools will be migrated to the Commission during the handover phase. To setup the help desk, the contractor will need to perform activities such as (but not limited): selecting and installing monitoring and administrative tools, preparing procedures, writing documentations, organizing training, etc Packaging and Deployment The EESSI system will be deployed in three classes of environments: the Coordination Node will be deployed in the Data Centre of the European Commission and must conform to the standards of the Data Centre (see annexe T4). It will interface with the stesta network the public web interface for the Directory will also be deployed in the Data Centre of the European Commission, and must therefore conform to their standards but it will interface with the public Internet so it will be on a different logical network and server the Reference Implementation will be deployed in the Access Points of the Member States throughout Europe. The number of AP can change over time. It will be deployed on dedicated hardware. It must be packaged to be easily deployed and upgraded by staff of the Member States. Special consideration should be given to the upgrade procedure, automatic upgrades and remote maintenance. It is expected that the contractor will provide the packages and procedures needed for these deployments. Call for Tender VT/2008/019: Administrative Specifications Page 74 of 101

75 Scalability and failover Traffic on the EESSI network is expected to grow over time. The exact timing of this evolution is not predictable at the time of writing as we do not know if or how many Member States will ask for transitional periods, which would delay their usage of the EESSI system. Therefore EESSI must be scalable, meaning it must be possible to handle traffic growth by increasing the processing power. Furthermore, increase in processing power must be as close as possible to linear with increase in traffic. Likewise, some information exchanges (particularly synchronous ones) are time-critical and therefore fail-over (the ability to replace promptly a faulty component with an alternative component) is crucial to the availability of the service. Possible technical solutions include load balancing, clustering, round-robin, load-balancing proxying, etc. It is expected that the contractor will design, develop and test each component with an eye towards providing scalability and failover appropriate to their technical and environmental constraints Orientations for a solution At this point in the document, we have covered the EESSI project from two different but complementary points of view: the project itself and the role of the contractor (which also serves as a framework to organise the tenders). This section deals with another aspect of the project: the unknowns. As with any other IT projects, there are many unknowns in EESSI. Indeed this is one of the (if not the primary) reasons to adopt an iterative-phased development approach. The Commission therefore expects that the pending questions will be resolved by the contractor as part of the normal proceeding of the contract. For example, as already noted, this includes a number of questions on the security implementation, the selection of products and tools, etc. The questions may be technically challenging but they are common in any project so we expect the responses to the EESSI call for tender to demonstrate that the team will have the ability to resolve them but it is not expected that the actual resolution be presented in the tender. There are however a small number of questions that are equally challenging but that are more specific to the EESSI project. The following subsections summarize them. Due to the nature of these questions, the tenderers should provide an answer to the questions in this section. The answer to the questions in this section must be fleshed out in sufficient details (including tools to be used, estimate of the effort, pros and cons, etc) so as to enable the Commission to assess how well the tenderer would resolve the problems. Inevitably, the answer must also include an evaluation on how the proposed solution addresses the problem Deployment in a very heterogeneous environment One of the challenges of this project lies in the status and the acceptance of the Reference Implementation. It seems that an RI with the facility and ability of accommodating plug-ins is not sufficient to address the problems emanating from the diversity of Member States varied architectures, e.g. databases. On the one hand, the Commission believes that adoption by most Member States of the Reference Implementation will promote interoperability and will hasten considerably the deployment of the network. It is also better use of community resources if more Member Call for Tender VT/2008/019: Administrative Specifications Page 75 of 101

76 States use the Reference Implementation and this would speed up the uptake of full electronic exchanges in social security as called for by the new Regulations 37. Moreover, it is envisaged that this should result in significant lowering of costs. On the other hand, the Commission recognizes that Member States have unique needs, that the situation is heterogeneous and that it will not be possible to accommodate all these varied needs through a single tool. Just to take one example, Member States which have already invested in application servers may prefer to extend their existing applications rather than install a new one. Likewise Member States have their own policies which may restrict the software that they can install. Consequently, for policy, technical, and procedural reasons, this call for tender recognises that the "one size fits all" approach is not workable. Indeed Member States have repeatedly expressed that view in the discussions of the feasibility study and have rejected proposals that depended on a mandatory RI. The feasibility study has not looked in great detail at how to address this problem and at the time of writing this call for tender the Commission does not have a preferred firm view on how to best address this duality between the legitimate needs of the Member States to control the software being deployed in their environment, and the legitimate desire of the Commission to promote interoperability through common tools. The Commission sees two approaches that could help address this challenge, although it is unclear whether they provide a complete solution or not. It is stressed that these are just proposals and it is hoped that other, better solutions exist and the tenderer is expected to shed some light on this aspect. The first approach is to increase the reliance on a few well-chosen plug-ins (described at above) and to provide sensible alternative implementations for the main commercial alternatives so as to give Member States as much flexibility as possible in the implementation of the RI. In this approach, the contractor delivers not only a plug-in framework infrastructure but also plug-in implementations for the most common commercial products. Those implementations would become part of the distribution of the Reference Implementation. Plug-ins could allow Member States to mix and match the RI with their own systems. The most important areas for allowing/developing plug-ins are indicated in above. Within that indicative range, an example would be to include plug-in implementations to support a range of different databases: one open source database (provided as default) and the most common commercial alternatives (Oracle, DB2). The former would fulfil the need of no licensing costs while the later would suit those Member States which have built their own national systems on commercial products 38. Note that this goes beyond just database drivers as it must account for differences in SQL support. We would expect the contractor to deliver a variety of plug-in implementations for database, cryptography, conversion services and control list access at a minimum. Obviously Member States would still be free to develop their own implementations for the plug-ins, say to support an unusual database, but in this scenario the core RI would already provide for significant support. 37 Subject to the transitional provisions to be negotiated in Council. 38 The Member States would cover the cost of those commercial licenses; presumably the cost would be low or nil thanks to the site licenses they have already deployed. Call for Tender VT/2008/019: Administrative Specifications Page 76 of 101

77 The alternative approach is to organise the RI as an open source project, with a code repository and the procedures to allow anyone (Member States, in practice) to contribute enhancements. The key in this approach is not so much to provide the source code to Member States but to have the infrastructure and procedures in place to allow Member States to contribute their improvements to the RI. Because of the EESSI procedural constraints, improvements will require the agreement of the Technical Commission for adoption as part of the RI. Ultimately the goal is similar: that is to give Member States the ability to tailor and customize the RI to their needs within a collective agreement. Drawing from the same example, if a Member State needs support for a certain database, it can dedicate the resources to adding the support for the database in the RI. Indeed, from the Member State viewpoint, one of the challenges when adopting the Reference Implementation comes from it being under the control of the Commission. An open source project would share the control among the parties, down to the most technical aspects. When looking at such a solution, there is a view that the infrastructure and the submission procedures of an open source project are crucial. From the perspective of a Member State, it is essential that its investment in time and effort to add features will be incorporated in the main source code on agreement of the Technical Commission with a view to making it available in subsequent releases of the RI. From the perspective of the Commission, with a keen focus on interoperability, flexibility and easy deployment, it is essential to prevent forking 39. The last thing that the EESSI project needs is to provide Member States with the source code and have them build incompatible versions of the RI. This would ultimately be detrimental both for the Commission and for Member States. In their response to the EESSI call for tender, tenderers are asked to describe a solution to this problem and justify the solution with suitable references (either from projects the tenderer has worked on or from public references and knowledge). In other words, it is expected that the tenderers describe how they plan to remove as many technical obstacles as possible to the adoption of the RI by Member States while bearing in mind that each Member State will have its own unique policy and technical requirements, and infrastructure. Because of the subsidiarity principle, Member States are free to organize their own systems as they see fit and there's a clear and unanimous decision from the Administrative Commission to allow Member States to develop their own version of the IPAP, as long as it conforms to the common protocols. The solution can be either technical or organisational (as is explained in the first and second approach respectively) and must ensure that whatever solution is recommended, it achieves the result that meets the objectives noted above. It is stressed that the above approaches are provided as mere food for thought. The tenderer is more than welcome to propose an alternative strategy and justify that with the appropriate references (from the tenderer's own experience or through public references) Handover As expected, the EESSI project as a whole shall far outlive the project resulting from this call for tender. EESSI is expected to be operational for many years to come, and maybe even for several decades. 39 Forking means two different and therefore incompatible versions arising from the same source code. Call for Tender VT/2008/019: Administrative Specifications Page 77 of 101

78 Throughout the development and implementation of the EESSI project, a team from the Commission will work with the contractor to assist and assess the ongoing work. Towards the end of this contract, the Commission will enlarge its team to take over the operation and maintenance of EESSI. Obviously, the Commission expects the contractor to produce very good technical documentation and training to enable a smooth transition. Experience in the IT industry tells us that handovers must be carefully prepared. It can be difficult for a team to take over the work developed by another team. Even if the two teams have been working closely with each other, it can be difficult to ensure that all information and, most importantly, know-how, is being transmitted in the most efficient manner. It is therefore expected that the tender must include a handover plan, a description of the methodology, procedures, tools and documentation that the contractor will use to improve the chances of a successful and timely handover. The EESSI specific requirements for the hand-over are outlined in the Administrative Specifications, chapter Tests (FAT and SAT) All EESSI components will have to be thoroughly tested. It is expected that the contractor will carry out extensive tests. In addition, the Commission and the Member States will test. The test will have to be performed at technical and business levels. The technical level testing will concern the connectivity, the protocols, etc. The business level testing will aim at validating that an Access Point can successfully exchange Structured Electronic Documents - SED with its counterparties and according to the corresponding business protocols. For the testing of EESSI the three following phases must be considered and detailed by the contractor in a Global Test Plan which describes the testing strategy and methodology, the test cases, the tests acceptance case, etc: Tests performed by the contractor when developing the various EESSI IT components, these tests are generally called the Factory Acceptance Tests (FAT); Tests performed on site when the various components are installed in their production environment, these tests are generally called the Site Acceptance Tests (SAT); Tests performed in the live environment with the Member States. All EESSI components need to be tested. In addition, after installing the RI and implementing their NPAP, all Member States will need to test the EESSI functionalities. Since the Member States will have the freedom to develop their own Access Point according to the specification provided by the contractor, this national application is to be tested against an EESSI Testing Application before going live Factory Acceptance Test - FAT The contractor is expected to describe the testing strategy that will be conducted at the contractor s development site prior to the delivery to the European Commission. The factory test concerns the full business and functional testing of the application, including the Call for Tender VT/2008/019: Administrative Specifications Page 78 of 101

79 verification and validation of the reliability and interoperability all the EESSI IT components that should be delivered to the Commission, namely: the Message Relay System for the Coordination Node the Information Repository, the Directory Service (Master and Public), the Reference Implementation (RI), the interface with the National Part of the Access Point (NPAP). FAT includes the functionality tests, the performance tests and the interoperability tests. For the factory tests the contractor will be expected to produce the following documents for approval by the Commission: The tests plan, which defines the testing strategy and the approach to be adopted, and how the test results will be documented The test acceptance plan that specify the success criteria The tests cases, which define the test scope and objectives, list specific conditions, which will need to be proven (processing pathways, data ranges, etc.), The Tests Report, which summarise the test campaign and results. This must include test cases and results against each test case, stress test cases and their individual results Site Acceptance Test SAT The site tests takes place once the various EESSI IT components are delivered in the production environment and aims at verifying that the various EESSI IT components perform according to the specifications in the production environment. Here again, the contractor is expected to tests all the EESSI IT components and is expected to produce the tests plan, tests cases, the test acceptance plan and the tests report and to submit them to the Commission for approval Performance Tests of the Message Relay at the Coordination Node The Message Relay - MR is the most critical component of the EESSI architecture, since it will act as the sole message hub through which all EESSI messages will be exchanged. The MR must be able to cope with peaks in demand for message exchange, particularly for messages requiring on-line response (i.e. entitlement to healthcare and postings of workers). It is important that there is a high degree of confidence that the MR will cope satisfactorily under stress conditions (high volume of message exchange). Performance testing aims at verifying the ability of the system to execute specific functions within accepted periods of time depending on the load that the system is subjected to at that time. These tests consist of performance tests conducted under specific conditions, stress tests, and volume tests (tests regarding large amounts of data). The Message Relay will have to undergo stress tests in the Data Centre of the European Commission according to their internal rules. The contractor will be asked to produce test scripts for that purpose to simulate peaks in the exchange of SEDs Call for Tender VT/2008/019: Administrative Specifications Page 79 of 101

80 Testing application For both technical and business tests the contractor is required to develop inside EESSI a testing application simulating two levels of testing i) one counterparty Access Point and ii) multiple counterparty Access Points as illustrated in Figure 21 Level 1 testing application Nationally developed access point Simulation of an access point Level 1 testing Level 2 testing application Nationally developed access point Simulation of access point of MS 1 Simulation of access point of MS 2 Level 2 testing Simulation of access point of MS n Figure 21. Testing applications Live Tests The live tests mainly concern the whole infrastructure with the Member States. The Member States have been asked to volunteer to perform the following real-life tests. It is foreseen that up to six Member States will participate in the tests. Please see annexe A3 40 for Member States participating in the testing of EESSI, primarily the testing of exchanges in all social security sectors Tests for the EESSI Master Directory The tests to be performed by volunteer Member States will mainly consist of; testing the installation of the software, testing the bulk upload facility, and testing the possibility to insert/edit/modify/delete single records in the EESSI Master Directory Tests on the Reference Implementation (RI) Web interface for clerks The tests to be performed by volunteer Member States will mainly consist of; testing the installation of the Reference Implementation, testing the local facilities of the Web interface for clerks (prepare, store, print, view, attach in the SED, etc), testing the exchange facilities of the Web interface (sending SED, receiving SED), and 40 At the time of writing, more than six Member States have volunteered for early testing. When the contract starts, six of them will be selected according to the country s capacity to test EESSI exchanges in all sectors. Call for Tender VT/2008/019: Administrative Specifications Page 80 of 101

81 testing the various tools of the RI (administration of the RI User Management, Access Control, automatic update mechanisms and other tools that will be specified later by the contractor) Tests on the Reference Implementation (RI) national connectivity (NPAP tests) The tests to be performed by volunteering Member States will mainly consist of; testing the communication channels between the RI and the national applications (send and receive functionalities), testing the XML SED Building capacity of the RI, the file packaging, and testing conversion, encryption/decryption, etc facilities provided by the RI Test on the Business Flows procedures The Web interface for the clerks is supposed to implement some part of the business flows in terms of business logic (e.g. a clerk receives a SED_ entitlement request ; is expected to answer with a SED_entitlement_Information ). The business logic implemented in the RI will have to be tested. For that purpose the contractor will be required to provide series of test cases that the testing Member States will be asked to carry out. It is important to underline that the purpose of this testing activity is not to test the content of the SED but the business logic implemented in the Web interface to be used by the clerk. It can be assumed at this stage that each flow (diagram containing several arrows describing the exchanges of information in application of a particular Article of the Regulation) identified by the Ad Hoc group will correspond to one test case. To ensure sufficient testing in this area it is envisaged that volunteer Member States will be required to run about 40 test cases each 41. The tests to be performed by volunteering Member States will mainly consist of; running about 40 different test cases each provided by the contractor Tests on the Information Repository The tests to be performed by volunteering Member States will mainly consist of; testing the download facility, testing the upload facility. For the purpose of the real life test the contractor is expected To prepare the test scenario for the Member States, To prepare the business logic test cases, To assist the Member States through a help desk during the whole test campaign. 41 Annexe T1 shows that at present some 120 flows have been identified. Assuming that each flow will have to be tested by two countries (most flows involve two countries, although a handful involve more than two), for each flow a test will imply actions from two countries. This means that there will be slightly more than 240 roles in the flow tests. Thus, the planned six countries will have to play on average just over 40 different roles each. Call for Tender VT/2008/019: Administrative Specifications Page 81 of 101

82 Nationally developed IPAP tests Member States have the possibility to implement their own national IPAP (International Part of Access Point). This national development will have to be tested. The testing application has been foreseen for that purpose. The contractor is expected to produce along with the testing application all documentation related to the carrying out of the tests, success criteria, etc. that a Member State will have to perform before being allowed to exchange SEDs with other Member States Test and Production System The contractor is asked to deploy the Coordination Node in the Commission Data Center. The deployment is phased with a test system being introduced first, a complete system following later, completed by running the system in an operational mode for the last 6 months of the contract. The Directory service is under a tighter timetable as it needs to be operational one year after the start of the contract and thus for a full year until its end (please refer to the deliverables section for the schedule). This section is concerned with the move from testing to production. Ultimately the Commission expects to be running two (or three) systems in parallel: a production environment, a testing environment and possibly a development environment. The production environment would be used for production data, the testing environment would allow Member States to test without disrupting production and the development environment would offer a view of the latest development version. The contractor will first install the testing environment and use it for an initial testing phase. The Commission's testing team will validate this version before it is installed into production. For the production phase however, the contractor will install a second production environment and upgrade the test environment. As is common, the test environment should contain a copy of the databases, user lists, etc. from the production environment with facilities to refresh the test databases from the production environment periodically. The Commission's testing team will be testing the system components as they are put into production, starting on the test site. There will be a need for a procedure/application for the testing team to flag and keep track of bugs as they find them and request the contractor to provide corrections. This joint working will start in the first year of the contract as the first partial deliverables are installed at the Data Centre and will intensify in the last 6 months of the contract when there will be a strong focus on making the EESSI system reliable. Tenderers are requested to suggest applications and/or methods that they have experience with. The contractor will define with the approval of the Commission methods, procedures and applications to manage the error finding and correction process Stress tests These tests are designed to evaluate the ability of EESSI to scale as traffic grows and its failover capabilities. Again the contractor is expected to test all EESSI components, to demonstrate their ability to scale as linearly (or almost as linearly) as traffic and to handle the expected load (see traffic estimates in annexe T3) as well as their failover ability. Stress tests need to be carried out also as FAT tests, before the system is deployed at the Commission's Data Centre. The contractor is required to document how the applications have passed successfully the FAT stress tests. Call for Tender VT/2008/019: Administrative Specifications Page 82 of 101

83 Security Tests From the first implementation of the EESSI components on the production site (starting with the first version of the Master Directory at the Data Centre), security tests must be applied. Tenderers should outline the main characteristics of their test plans, which the contractor will have to detail in their first report. This must include as a minimum Black-box penetration testing Current standard testing techniques The security test plan should be based on an assessment of EESSI's security risks, also to be delivered at the beginning of the contract. It should outline foreseen attack patterns and threat models Deployment of the EESSI components Migration of the CLD data into the Directory System Once the Directory Service is up and running and tested, the contractor will have to organise the migration of the data stored in the CLD into the new system. The current data are stored in an Oracle Database from which the data will be exported into a popular exchange format. For information the complete content of the CLD is already available in xml format Uploading of the national data into the Directory System Once the CLD has been migrated, the contractor should organise and assist the upload of the national data of the Member States according to the specification provided by the contractor. The Member States, sometimes sector by sector, will bulk upload the complete list of their national institution Population of the Directory System Once national data are uploaded in the directory, the replication mechanism could be activated and the data made available to the public through the public directory system. At the same time, local copies in the national access points will be performed Deployment of the Co-ordination Node (CN) and RI The Co-ordination Node will be deployed in stages and the first component that will have to be deployed is the Directory Service, mentioned above. The Messaging Services and the outstanding components will be deployed later, with a first complete Co-ordination Node required by the 18 th month. The contractor will not be allowed to interact with the Commission's Data Centre directly. Commission staff will be carrying out this task. For this task, the contractor will have to provide all required tools and assistance and fill in any forms/requests that may be needed. The deployment process will be repeated each time a new version of the CN must be installed. 42 See Call for Tender VT/2008/019: Administrative Specifications Page 83 of 101

84 The RI must be co-ordinated with the CN components that are progressively made available and installed. The RI is to be installed in the countries' Access Points (and a few instances at the Commission, for testing and its own business use 43 ). Although it is foreseen that functional changes to the applications are generally done a few times a year, the continually new versions that the contractor will have to produce after the first installation of each component are likely to be much more frequent. These will aim to correct major and cumulatively important errors and will have to be produced in a short time. This close iteration process aims to ensure that the installed components work as requested. Thus, after the components' first installation and throughout the remainder of the contract, the contractor is expected to produce a large number of corrective versions. The tenderer should indicate their practices in terms of issuing new builds of the applications they prepare and install, with a view to applying those practices to EESSI. 4. Protocol Design and Document 4.1. Introduction There are three aspects under this topic: the design of the protocol between the Access Points and the Coordination Node the design and development of the SEDs the LDAP protocol The basics of the protocols have been decided during the feasibility study: based on Web Services protocols and, more specifically SOAP (e.g. not REST, not ebxml). Work on the SED has already started by collecting information on the business protocols. In addition to the protocols below, the contractor is to provide an assessment of the hardware requirements for the system, both at the Coordination Node and at the Access Points a proof-of-concept, to encompass the hardware, software and message specifications 4.2. Messaging Service: Fundamentals The feasibility study has identified the following functional specifications for the EESSI Message System (EMS). The contractor will need to design, document and implement a protocol that conforms to these requirements. First and foremost, the protocol must make the use of the Coordination Node mandatory: any exchanges between two Access Points must take place through the Coordination Node, this is a fundamental decision. See Figure 22 for an illustration of the use of the Coordination Node. 43 The European Commission (PMO) will participate in the social security exchange, albeit in a small number of cases. Call for Tender VT/2008/019: Administrative Specifications Page 84 of 101

85 National Network National Network National Network Member State 2 Member State 1 EESSI Backbone Network EESSI International Domain National Network Member State 3 Member State 4 National Network National Network Coordination node Access point EESSI international part of access point EESSI national part of access point Figure 22 : mandatory use of the Coordination Node According to FS-45, the protocol must offer push and pull messaging, each CI being able to choose their preferred way. The exchange between the Access Points and the Coordination Node will be based on SOAP messages with WS-Security or XML Signature enabled. L2:FS-45. EMS shall provide functionality for receiving unsolicited messages from another sending EMS site, or by polling a sending EMS site. Most exchanges between Member States take place in batch mode and are relatively infrequent; therefore the protocol can support asynchronous exchanges of large files (FS-56). Those exchanges place little constraints on the time for delivery. However there are two special cases: checking of healthcare entitlement and the posting of workers (currently "form E101", but to be replaced in the near to medium term future). In the former case, the sending of the request and receiving a response has to be made within the same connection (or session). To accommodate for those exchanges, the protocol must provide for synchronous exchanges, as dictated by FS-46. Call for Tender VT/2008/019: Administrative Specifications Page 85 of 101

86 L1:FS-56. The EMS shall allow the transport of large files. If necessary, large files may be broken in smaller parts and reconstituted at the receiving side. L1:FS-46. EMS shall provide facilities for the exchange of messages within a single session in a query and response paradigm. The contractor will need to analyze the requirements further and decide whether a single protocol can address both needs or if two protocols (or variants of a basic protocol) are needed. Obviously, given much of the information relates to payment and the rights of citizens, the messaging system must deliver excellent error handling and tracing, as explained in FS-47 and FS-58. L2:FS-47. EMS shall provide status information to the sending side about the successful or otherwise completion of the message transfer. L2:FS-58. EMS shall gracefully handle network failures. It shall automatically resume full operational status when the network is up and running. Strictly speaking, the routing information could be extracted from the SEDs themselves in most situations (because the SEDs will include references to the sending and receiving institutions as well as case number, citizen identification and other information), although encryption could well make this information unavailable. Therefore, it was decided to rely on more traditional routing, based on an envelope. Amongst other benefits, it will enable the messaging system to route data in any format (including XML documents but also binary files such as images or PDF documents). L1:FS-48. Message headers shall contain all the necessary data for the further processing, routing and delivery of messages to their recipient. L1:FS-49. Message headers shall be processed in a standardised way L1:FS-50. EMS shall be able to transport any type of files. All information specifying addressing, routing and processing of files shall be contained in the message header Point-to-point and publish/subscribe Point-to-point refers to sending a message to a single recipient. Since the bulk of information will be exchanged between Access Points (with the coordinating node acting as an intermediary), this will be the predominant type of messaging. Publish-and-subscribe may only be needed for the distribution of configuration-type or control-type of information. For instance, when critical information is modified in the EESSI Directory, some Member States may wish to be notified immediately about those changes. The Coordination Node may implement a publish service for announcing important changes. Member States may opt to subscribe to this service for receiving automatic notifications. L1:FS-52 EMS shall predominately transport messages in a point-to-point manner L2:FS-53 EMS may make available a publish-and-subscribe service for configuration and control information Call for Tender VT/2008/019: Administrative Specifications Page 86 of 101

87 Broadcast In a few extraordinary cases, it may be necessary to deliver notification to multiple recipients simultaneously. This does not concern the exchange of SED, but the exchange of control or signal information, such as unscheduled unavailability of an EMS site (e.g. an Access Point). To provide support for those types of messages, EMS should provide facilities for the broadcasting of messages to a list of recipients while ensuring that the broadcast reaches each intended recipient once only. The contractor will assess the real need for this as it may effectively duplicate the publishand-subscribe service. As part of the design protocol activity, the contractor will need to review the specifications (particularly level 2 specifications those prefixed L2 that were introduced in the study without referencing the needs expressed by Member States), find and eliminate duplicates and decide on the most efficient protocol. L2:FS-54. EMS may provide a broadcast service for control or signal messages with a dynamic list of recipients Routing Given the fixed topology of the EESSI network, dynamic routing is not needed in the international domain. The feasibility study foresaw static routing, since every message will be routed through the Coordination Node in a fixed topology. The contractor may mitigate this against the facilities provided by the Web Service stack. L2:FS-51. EESSI shall be based on static routing Support for large messages L1:FS-56. The EMS shall allow the transport of large files. If necessary, large files may be broken in smaller parts and reconstituted at the receiving side. In addition, very occasionally even larger files may be sent. This can be the case when medical imagery is required to process a claim. The EESSI system should be able to cope with these Messaging Service: Reliable Messaging Guaranteed message delivery Reliable delivery of messages is fundamental to the smooth and efficient functioning of EESSI. While the EMS will operate over a reliable network (i.e. the EESSI backbone), for the smooth functioning of EESSI, EMS nodes have to be tolerant of other s EMS nodes non-availability (both short term and long term) and be able to deliver messages reliably. Furthermore, only a single copy of a message must be transmitted. Duplicates should be automatically deleted. SOAP, which has been chosen as the protocol underpinning the message service is a best effort protocol: it does not guarantee delivery or processing of messages. Call for Tender VT/2008/019: Administrative Specifications Page 87 of 101

88 It is felt that, given the nature of the messages, their importance for the service to the citizen and the monetary flows that they represent, a reliable messaging must be built on top of SOAP. Reliable messaging must guarantee delivery of messages (FS-55) and guarantee the sequence of messages (FS-57). L2:FS-55. EMS shall reliably deliver messages to the recipient EMS. Messages shall be sent once only and any duplicates shall automatically be removed Sequencing of messages Under certain conditions it may be important that messages are processed in the order they were sent. For instance, an acknowledgement that a SED was routed to a Competent Institution has to be processed after the acknowledgement that the encoding of the SED (i.e. the XML format) was validated and passed all checks. For a variety of reasons, including temporary network failure or message queue management, the receiving side may receive the messages out of sequence. The messaging system must be able to notify other processing layers the order the messages were sent, so that those other processing layers process the messages in the appropriate order. L2:FS-57. The EMS shall provide data for the sequencing of messages by the sending side Network error handling The EMS should handle both short-term and long-term network failures gracefully. No manual intervention should be needed to reset EMS to recover from network failures. L2:FS-58. EMS shall gracefully handle network failures. It shall automatically resume full operational status when the network is up and running Message processing loads alerts An EMS may reach a state in which there are more messages being sent than those the EMS can process. When such a state is reached, the EMS should alert the sending EMS(s) that the maximum receive rate was reached. To prevent message loss, it is essential that messages be persistent. L2:FS-59 EMS shall implement a mechanism to alert other sending sides about its ability to process more incoming messages Security Security ranks high in the establishment of a reliable messaging solution and this is reflected in FS-64. Note that the decision to use stesta as well as mandatory encryption between Access Points and the Coordination Node (using WS-Security or XML Digital Signature) are concrete steps towards FS-64. L1:FS-64. The security provisions and the architecture of the underlying data exchange network shall provide the basis for the trust between access points Call for Tender VT/2008/019: Administrative Specifications Page 88 of 101

89 Confidentiality, integrity and non-repudiation of message origin are all foreseen in the specifications (FS-65, FS-66 and FS-67). L1:FS Access points shall provide encryption facilities at the message exchange level; those may be used in cases higher layers of the access point services have not encrypted the contents of the message. L1:FS-66. The EMS shall protect integrity of messages in transit, and at rest; it shall provide the means to verify the integrity of a message. L2:FS-67. The EMS may provide functionality to provide evidence for the non-repudiation of messages. The functional specifications also foresee the use of transport-level security (FS-68 and FS- 69). In practice this seems redundant (and expensive) with the use of encryption at the message level and the use of encryption at the network level. The contractor will need to review the needs and make suggestions. Note however that this is a level 1 45 recommendation. Last but not least, although strictly speaking not a protocol feature, extensive use of logging has been foreseen (FS-70). However this will require session identifiers at the messaging level to track exchanges properly so it has an impact on the protocol as well. L1:FS-68. Access points shall provide functionality such that they identify and authorise each other. Digital certificates may be used for such purposes. L1:FS-69. Access points shall provide network transport level encryption (e.g., SSL, HTTPS). L1:FS-70. All information exchange transactions shall be logged for future reference Messaging Service: Specifications and Development The Member States are free to use the Reference Implementation developed for the Commission by the contractor or to develop their own implementation. The development of the messaging service will reflect this by: Focusing on the development of a messaging protocol, that follows accepted standards and industry best-practices but, most importantly, that is independent from any given implementation. It is expected that the protocol may be amended over the course of the development, provided that those modifications are approved by the Commission and properly reflected in the documentation and validation suite. Expanding appropriate efforts to document completely the protocol. The documentation must include both the formal, machine-readable specifications (e.g. WSDL) and technical documentations for developers. It will refer to existing standards whenever appropriate. It is expected that the document will evolve over time to integrate the experience of the implementators (both the contractor and the 44 Please note that the Technical and Administrative Commissions have agreed on the mandatory automatic use of Web-Services security between Access Points this means that all messages will be automatically encrypted from Access Point to Access Point (see Annex A3, page 17). 45 In the Committee discussion on the recommendations of the Feasibility Study, some specifications were labelled as level 1. This means that they originated directly from user requirements. In the syntax above, level 1 specifications are preceded by L1. Call for Tender VT/2008/019: Administrative Specifications Page 89 of 101

90 Member States) so it should be structured to enable this evolution (e.g. a wiki or commented documentation, similar to JDocs would be ideal). Creating a validation suite that will enable regressive testing of any protocol implementation. The validation suite will test both for common cases and exceptional cases. The validation suite will serve as the first step in the certification and acceptance of any implementation. It is expected that the validation suite will be developed over time and it should be structured as such. More specifically when a new class of problems is discovered in one of the implementations, the validation suite may be updated to exercise and validate those problems. As much as possible, it should be built over a testing framework (e.g. Cactus, JUnit, etc.) to ease maintenance and evolutive maintenance by the Commission. Last but not least, the implementation of the messaging protocol, as part of the Reference Implementation and the Coordination Node, must, of course, pass the validation suite Messaging Protocol: Patterns During the preliminary work on the business protocols (see below), a number of basic patterns for the messaging were identified: question/reply where one party requests information from another party sd: RequestReply PartyA :CompetentInstitution PartyB:CompetentInstitution 1).request 1) reply notification where one party notifies the other party of some change sd: Notification PartyA :CompetentInstitution PartyB:CompetentInstitution.notify It is expected that the other common patterns in messaging systems (e.g. subscription, proxy, multicast, etc.) are being used as well. Obviously the messaging protocol must, of course, be able to transport all of these patterns but there is a view that it is desirable to build the protocol around these patterns, i.e. have request/reply, notification, subscription as protocol Call for Tender VT/2008/019: Administrative Specifications Page 90 of 101

91 verbs. It is expected that the contractor will analyse this need, propose a solution and implement it in the protocol Business Protocol: Importance of Flexibility Obviously the messaging protocol is vital for the operation of EESSI but the most important protocol is the business protocol that specifies the exchange of messages between the Competent Institutions. Within EESSI the messages are called SED (Structured Electronic Document). The definition of the SED is derived directly from application legislation. In other words, in EESSI, it is the European legislation on social security that defines which institutions need to exchange what information under which circumstances. Although, broadly speaking, the legislation is stable, it is still a living and evolving body of work. More specifically: legislation changes due to political changes or legislation changes within the Member States, and the changes are not always predictable the European legislation on social security is a coordinating legislation, so the business evolves as the national legislations evolve a new regulation is being introduced. In fact its introduction provides the impetus for EESSI. However the new regulation is being worked out while the technical infrastructure is under development. By nature the two developments are concurrent. So it is not possible to firm up the business protocol completely until the very last minute. Therefore the focus in the development of the business protocol is on the flexibility and adaptability of this protocol. The need for this is expressed in Last but not least, work on this business protocol has already started in two forms: experts from the Member States, organized in Ad-Hoc Groups, have been analyzing applicable legislation for several months and they have been trying to extract basic information needed to create the business protocol analysts from the European Commission have been taking the results of these working group and formalizing them in one UML model. The results of the work so far are annexed to this Call for Tender but it is essential to review those results with an eye on the timeline: work is still under way in these matters and by the time the contract is awarded, work will be further developed than it is today. To summarize this point, the Commission is not looking for a hard-coded system that requires extensive software development efforts when the flows or the SEDs need to be modified. Instead, the Commission expects that the contractor abstracts as much of the definition of flows and SEDs into models and other descriptive documents that can be maintained by nondevelopment staff (obviously trained and technically proficient staff but not necessarily developers). In more concrete terms this will require moving controls, validation, flow definitions, data definitions to parameter files and not hard-code these. The maintenance of these parameters files will be done primarily through a UML model, in a method that borrows heavily from Call for Tender VT/2008/019: Administrative Specifications Page 91 of 101

92 Model-Driven Architectures for software development although in this case it is not applied to software development. To support the maintenance of the SEDs and business flows, the contractor will provide SED and business flows modelling tools, as described in the following sections Business Protocol: Guiding Principles for SED A number of functional specifications from the feasibility study relates to the SED. Specifically the SED will be based on sets of standardized elements (FS-27), the preferred encoding format will be XML (FS-26, FS-28, FS-29). Recognizing that XML encoding is not appropriate for non-textual information (typically images, as found in medical records; the feasibility study refers to non-textual information as unstructured information), the use of other encodings is supported but will be phased out for XML-codified information (FS-30, FS-31). L1:FS-26. The preferred encoding of SED is XML L1:FS-27. Data elements in the XML shall be standardized. L1:FS-28. Currently existing non-xml encodings of SED (e.g. EDIFACT, MTF, MS-Excel) shall be valid formats for the exchange of SED. L1:FS-29. Non-XML encodings of SED will be phased out. The timing of the phasing out shall be determined by the Technical and Administrative Commissions. L1:FS-30. Structured data (e.g. the fields of the present E-xxx paper forms) shall be encoded as XML data elements. Non-structured data (e.g. images accompanying a medical report) shall be non-xml electronic files attached to the XML-encoded documents. L1:FS-31. EESSI will provide facilities with which Competent Institutions will be able to exchange unstructured information, including the exchange of text and binary files, on an ad-hoc basis. In view of the fact that alternatives to XML (JSON) are beginning to emerge for Web Services, it is desirable to take a bird-eye view on the business needs as opposed to the lowlevel discussion on the syntax. Furthermore the Member States have also decided to document their business procedure in UML (using a methodology suitable for message development) with an eye towards applying MDA (Model Driven Architecture) techniques to the development of the business protocol. Specifically, it has been decided to describe the business operation in a formal model (written in UML) from which the human-readable documentation and the technical specifications (XML Schema, WSDL, etc.) will be extracted. The purpose of models is to aid the design of solutions. They assist in the understanding of the problem and aid deliberation and choice by allowing the evaluation of the consequence of the action before implementing. Models support decision making, not vice versa. Call for Tender VT/2008/019: Administrative Specifications Page 92 of 101

93 In practice it is pretty straightforward. The Ad Hoc Groups deliberate on the flows and the data they think is needed, for instance in one sector. The work done by the Ad hoc groups requires agreement of the Administrative Commission before the agreed results of the Ad hoc groups are used by a group of modelers who formalize these results. In other words, once there is collective final agreement in the committees on the flows and data set, in for instance one sector the purpose is to then extract the documentation, flow descriptions and SED definitions using the model Business Protocol: Borrowing Concepts from Software Engineering At this stage, no known modelling tools satisfy the following EESSI needs completely, namely: UML compliant Ability to express needs in business terms Extract and generate XML artefacts Although there are case tools that generate XML artefacts (e.g. hypermodel), they typically require the model to be built around XML definitions with very extensive use of stereotypes and tags that are very specific to XML. Unfortunately, this does nothing to improve the readability of the model and it forces business people to deal with the intricacies of XML. You could equally well be working directly with XML Schemas and any flow description language. In contrast, the desire is to focus on a more business-centric view. The model is annotated with stereotypes and tags but as much of the intelligence as possible is pushed to the model querying, i.e. the routine generating XML Schemas and other documentation. Also it should be stressed that the model is not limited to data description (static view) but includes specifications (use case) and dynamic views (flows) as well. The Commission has tools to perform this extraction, which were developed to support the use of modelling under the previous legislation but those tools (mostly XSLT style-sheets that work on XMI representation of the model) are not user-friendly or robust enough to support the amount of work envisaged. The contractor is expected to modernize and firm up those tools and turn them into fullfeatured SED and business flow tools that will: Produce reports on the quality and status of the model, find duplicates, find incoherencies, missing information and other reports useful to the modelling team Produce documentation in a human-readable format: Word, HTML, PDF or another suitable format Generate the XML artefacts (XML Schema, example files, WSDL documents) for the messages and the flow definitions Call for Tender VT/2008/019: Administrative Specifications Page 93 of 101

94 Generate configuration files for EESSI such that when the model is updated to reflect changes in the business (e.g. changing a business flow to introduce one new SED and update another one), EESSI is automatically configured to handle the new data Generate the MTF definitions for the data conversion described above Interface with the information repository to publish the updates automatically A need for retro-engineering tools is not anticipated since the business flows are new and will be modelled early. The European Commission has selected Poseidon for UML from Gentleware as its tool to produce a UML 2.0 compliant model (Poseidon acts as the front-end). Poseidon data can be queried either through Velocity templates or directly from an XMI export. Currently the Commission exploits the XMI export. Since the SED and business flow tools will be disseminated widely in the project and the goal is to push its use towards the business experts, it must be friendly to use and integrate well with the UML front-end. For this development, the contractor will interface with the Commission modelling team (including, but not limited to, the workshops foreseen in 4.9 below) Business Protocol: Workshops The amount of work needed to process the output of the Ad-Hoc Group exceeds the capacity of the modelling group before the contract starts and therefore the successful tenderer is required to provide assistance. Some modelling will continue during the contractual term. At that time, the contractor and the Commission's technicians will work closely with a view to making sure that there is mutual understanding on what is required and what can be made available. On one hand, the contractor will be developing the framework that will host the data, message and flow definitions; on the other hand, the Commission will have created the definitions in UML form, and with the help of the contractor, will be finalising and creating the remaining definitions in UML form to be inserted into the framework. Specifically, a maximum of four workshops are to be organised where the Commission s modelling team and experienced modellers from the contractor will process together the remaining results from the Ad-Hoc Groups, as well as review the work already carried out by the Commission. The workshops will last no more than three days each and be organised by the Commission and held in Brussels during the first year of the contract term. Inevitably there will also be some preparatory work before the workshop(s), as well as some work between the workshop(s). This plan is provisional and subject to change in agreement between the Commission and the contractor bearing in mind the reality and progress during the contract term. Call for Tender VT/2008/019: Administrative Specifications Page 94 of 101

95 4.10. LDAP Protocol The replication of the Directory service available in the Access Points must be accessible through an LDAP interface, enabling other applications to query the directory with standard components and protocols. Note that the LDAP requirements apply to the replication available through the Access Points only; the Master Directory needs not be accessed directly, its role is solely to serve as a master for the replicates. Having written that, nothing prevents it from adopting LDAP and using it for the replication. As for the public interface which is accessible through the Internet, it cannot support LDAP and must be accessible through a browser-based interface exclusively. 5. Documentation Tenderers must to submit their documentation plan. Documentation concerns the delivered applications and services and supplements the information provided in the reporting, which applies to project report, risk and quality assessment. In this section tenderers will find guidelines for their plan. Tenderers are expected to have their own training and documentation standards. Bearing in mind that the following requirements are to be met, tenderers are free to submit plans that are in line with their practices and structures. The documentation should address the need-to-know of several types of actors who will work with the EESSI system. It must be kept up-to-date. If, within the contract lifetime, the application is modified, the documentation is to be made consistent with the changes Developer Documentation The main applications will have to be documented with a view to allowing developers to maintain it and build interfaces to it. Tenderers are to submit a documentation plan and standards that can be their own; however, this should be seen in the context of the RUP or RUP-like (any other iterative software development process) framework, which should be implemented to carry out EESSI. The documentation must include at least the following. For both the Coordination Node and the Reference Implementation for the Access Points, the contractor has to provide a correct, clear and complete documentation of the applications. This is to enable the Commission to take over the responsibility for maintaining the applications. The protocols foreseen in 4 must be documented in detail. The documentation must stem from the applications, where particular care should be taken in documenting steps in the code itself, with a view to having standard documentation tools produce a clear API. In addition, there should be overall descriptions of the main building blocks. The developer documentation will be tested during each delivery phase, with a view to testing its correctness and completeness. The contractor also has to plan tests of the documentation in its quality plan. The documentation will be provided in English. Call for Tender VT/2008/019: Administrative Specifications Page 95 of 101

96 With a view to ensuring development and evolutive maintenance, the Commission will require the Coordination Node and the Reference Implementation documentation in depth and accompanied by thorough training and mentoring in the hand-over phase. National administrations will require documentation for the two applications at different levels, as described hereafter Coordination Node API Developers in countries that choose to build their own AP implementation will need a precise and reliable API of the CN with a view to connecting to it. This is in addition to the protocol (see 4 ) This documentation should be kept separate from the main block, since it must be used as a basis for implementing a country's own implementation, as well as the Reference Implementation Reference Implementation API Here the main purpose of the documentation is to allow national administration to Make use of the modular (plug-in) structure of the RI, with a view to easing the interface with their own systems and networks Interface it with their own systems and networks National administrations will be hard at work on their interfaces to the EESSI system. In particular, those that participate in the early test sessions will, at the same time, be testing the documentation. In addition, for both the CN and the RI, the contractor has to provide for installation manuals, for the benefit of the system administrators at the Commission's Data Centre and in the national administrations End User Documentation Although it is expected that most messages will be sent automatically, there are several parts of EESSI that are accessed directly by people and these need to be documented. End-users will need a "getting started" as well as a reference manual covering all of their actions. These include at least The Directory (in Read-mode) The web interface for the clerks, allowing clerks to introduce information into a frame to build and send a SED The consoles at CN and RI levels The interface to update the Directory Consultation of the CN information repository, including its tools Access to documentation, support and learning modules 5.3. Trainer and support documentation In addition, the contractor will provide special manuals for help desk personnel and trainers. These must cover trouble-shooting, common pitfalls, how-to modify the e-learning modules, Call for Tender VT/2008/019: Administrative Specifications Page 96 of 101

97 instructions on how training should be approached, case studies, examples, and be supplemented by any other material that the contractor has produced and/or used for its support and training provision. Of particular importance here is the documentation on the message logging and tracking, with a view to enabling the support teams to identify sources of messaging problems Administrator Documentation It is hard to distinguish between EESSI administrators and end-users. This section is about administration functions, ranging from access right management to directory upkeep, language and central node administration, including the management of the data, message and flow definitions. Administration documentation will depend ultimately on the specific architecture that the tenderers suggest. Hence, it is up to the tenderers to ensure that their development plan is supplemented by a suitable documentation plan and to make this clear in their tender. 6. Training and Help Desk 6.1. Training The contractor is required to provide for end-user, administrator and developer training. The last instance will be part of the hand-over. In addition, the hand-over will include enabling the EESSI administrators to run the system and provide end-user training. End-user training will depend on the interfaces that the contractor will make available; the subject will range from the making and sending of the SED to consulting and editing the Directory 46 ; it must include the web interface for the clerks as well as basics for interfacing with the IPAP messaging. It is expected that there will be some Access Points that will operate the EESSI system from the Member States' side 47. It can be estimated that there will be 3-4 people per Access Point who will need training, for a total of people. The contractor will not be required to organise the training in each national location. However, they will have to get organised with participating countries at 5-6 decentralised core locations 48, to which people from neighbouring countries will have to travel. It is up to the tenderers to plan and clearly specify - the duration and content of such training, which should be consistent with their planned development. In addition, the contractor should make provisions for presentations to larger audiences in Brussels. Further end-user training needs to be organised in Brussels for the central administrators. This should be similar to the training offered to national end-user, and could be extended to include administration training (if not, separate administration training must be offered in addition). The contractor will need to develop e-learning modules, using a framework that will allow them to be translated easily. The contractor will only be required to provide the English version; other versions will be provided by the Member States. As specified above (see ), a master copy of the e-learning modules will be stored in the Information Repository 46 Note that national Access Point administrators are responsible for keeping up-to-date the directory information that concerns the Competent Institutions in their own countries. Hence they have also an administrative role. 47 As regards the expected number of Access Points, please refer to annexe A3. 48 Tenderers are required to specify the locations that they will use to offer training in their plan. There should be locations in peripheral regions, for instance one in Scandinavia, one in Eastern Europe, one in Mediterranean Europe, one on the Western fringe, in addition to Brussels. Call for Tender VT/2008/019: Administrative Specifications Page 97 of 101

98 in the Co-ordination Node. Tenderers are required to provide a plan on the subjects and extent of the e-learning modules. The contractor is to organise and provide administration training in Brussels for the benefit of the central administrators. There could be up to ten central administrators. This should cover all EESSI central operations that do not require updates to the application code and can be implemented outside the IT framework for application iterations. In the framework of the hand-over, the contractor is to organise training for the Commission's IT people who will manage the application at the end of the contract and will be in charge of the iterations. This concerns coding, testing, deploying to the CN and the APs, modifying manuals and help-files and informing the end-users. Furthermore, there should be a session of training or coaching for the trainer(s) who will take over the training task from the contractor. This could be organised as a joint end-user training session or close coaching on course preparation. Tenderers may depart from this specific task if they have their own methodology for enabling their customers to take over the training duty. Training plans in the tenders must outline the content of the courses, duration and the periods in which they are to take place, the instructors' qualifications, and the number of foreseen/allowed participants. Tenderers must make specific training plans so that they are assessed during the tender evaluation process Help Desk From the moment the EESSI system starts its testing phases, the contractor is to provide a help desk to accompany the central administrators and the national clerks to make a correct use of the system and escalate problems that need to be addressed. The main source of calls for help that are expected are the installation (at the Central Node and in the IPAPs), the communication protocol, working with the Directory, all the administrative tasks and the messaging. While this list appears to cover the entire EESSI system, it should be noted that the last item, i.e. messaging, will probably generate few calls outside the six early testing countries and that the calls of these will probably take place mostly during the testing period. During the course of the project, a help desk during normal working hours will suffice. This means that it should be ready to take calls from 9:00 to 17:00 CET, on Commission workdays. Tenderers are to submit a succinct support quality plan. The language of the help desk will be English. 7. EU Standards At the end of the project, the Coordination Node application is to be installed at the Commission's Data Centre. There are standards that need to be met in such circumstances. Tenderers will find enclosed (annexe T4) the data centre guidelines. Since the project is launched in the framework of IDABC (see ), it has to comply with its guidelines, in particular its architecture guidelines, which can be found at The project will make content available via web interfaces. Web interfaces must comply with IPG standards. These can be found at Call for Tender VT/2008/019: Administrative Specifications Page 98 of 101

99 As regards licensing, tenderers are requested to pay attention to the indications from the IDABC programme and in particular its EU public licence formulation (link within the page above). 8. Workplace and infrastructure For the duration of the contract, the CN application will be hosted and maintained at the contractor's premises, although whenever a deliverable is foreseen, the CN will be also installed and run at the Data Centre. In addition, the RI will be deployed into national administration's systems from both the contractor's premises and from the Data Centre. At the end of the contract the system has to be handed-over to the Commission; installation of the system onto the Commission's premises must commence in accordance with the agreed handover plan (see the Administrative Specifications for this, section 9). The contractor has to build a system that is suitable to be installed at the Commission's Data Centre. For this, the contractor must take into account the data centre hosting guidelines, i.e. annexe T4 and note that the system should be "in production" for at least six months. 9. Model of Monthly Progress Report The contractor is to provide several reports that focus on specific Deliverables when the deliverables are due (see the Administrative Specifications, chapters 7 and 8). In addition, the contractor is to Report to the Commission each Month on the work Progress. When the delivery dates of a Deliverable Report and a Monthly Report coincide, the contractor may deliver a combined report, provided that it contains the required information for the Deliverable and the Monthly Report. As regards the required contents of Deliverable Reports, there are indications in the relevant sections above. As regards the Monthly Progress Report, it must include the following information, in addition to any other information that the contractor will consider relevant. (1) Tasks planned during the reported month (repeating section 7 of the previous monthly report); (2) Progress during the month: For each task mentioned in the list under (1), and any other project task carried out, a short description of the contribution to the progress is given: description of the activities carried out; description of the results achieved; comments on ongoing tasks when appropriate; justification of the deviations from Section 1. (3) Relevant lists, statistics and indicators 49 regarding: Tests, Documentation parts, Training/Workshop/Demonstration, Communication with the Member States; Meetings, reference to reports, technical review; 49 Lists, statistics and indicators should be specified in the quality plan and can be modified in agreement with the Commission. Call for Tender VT/2008/019: Administrative Specifications Page 99 of 101

100 Any deliverable addenda, correction or pre-release instance; (4) The Deliverable Tracking Matrix showing the: Planned delivery dates; Foreseen delivery dates; Actual delivery dates for review and for acceptance; Along with justification of any differences between planned and actual dates; (5) The list of deliverables: (a) submitted for acceptance during the reported month; (b) delayed from this month and from previous ones with due justifications; (c) any departure from the expected quality; (d) mentioning the initially planned submission date for acceptance; (e) in case of delay or departure from the expected quality, remedies being put in place and a revised schedule (6) Risk management detailing problems and/or issues met during the execution of the tasks as well as any other anticipated risks. Expected or actual overruns of tasks and/or difficulties for meeting agreed target end-date should be explained here; The contractor will pay attention and report on the following topics: Risk Identification Risk Analysis Risk Planning Risk Tracking Risk Control Risk Communication (7) Tasks planned for the following month, as an extract of the project Plan, listing all the tasks that are planned to start or to be continued during next month. This list is the basis for point (1) of the following month s MPR. ( Tasks planned during the concerned month ) for the MPR made at the end of the next month; any departure from the time plan must be cleared with the Commission; (8) Planning of the Contractor s activity until the end date of the specific contract. In case of conflict between the MPR and the Project Meeting minutes (even when accepted by the Commission) on the one hand and the contractual documents, on the other hand, the latter will always take precedence. 10. List of Annexes The list below only contains references to the annexes of the Technical Part of the specifications, i.e. this document. In addition, once again, this document and its annexes (labelled T1 through T5) should be read jointly with the Administrative Specifications and its annexes (labelled A1 through A4). Call for Tender VT/2008/019: Administrative Specifications Page 100 of 101

101 Annex Title T1 EESSI flows T2 EESSI Data T3 Social Security indicative exchange metrics T4 Data Centre Guidelines T5 Directory Attributes Annex content List of identified flows, with a short note on the types of flows The data that compose SED messages An estimate of the amount of information that the EESSI system will allow to exchange Guidelines for installing applications at the Commission's Data Centre Competent Institution attributes and other directory specifications Call for Tender VT/2008/019: Administrative Specifications Page 101 of 101

102 EUROPEAN COMMISSION DIRECTORATE-GENERAL Employment, Social Affairs and Equal Opportunities Social Protection and Integration Coordination of Social Security Schemes, Free Movement of Workers Open Call for Tender VT/2008/019 Informatics services and products in the context of the EESSI (Electronic Exchange of Social Security Information) project Technical Specifications Annex T 1 Flows and messages Call for Tender VT/2008/019: Technical Specifications- Annex T1

103 Business flows in the EESSI system How to read the flow diagrams The following flows aim to give the tenderers an idea of what business the EESSI system should support and what kind of flows should be foreseen in the system. It must be pointed out here that the flows themselves (the diagrams below) were drawn by social security ad hoc groups of experts 1 and approved by the relevant Committees of country delegates. However, tenderers will find hereafter additional text that is provided for explanation. In particular, as separate flow groups were drawn by different experts, the text highlights for the reader different approaches and notations. As specified in the Technical Specifications, these flows are neither complete nor definitive. Nevertheless, they do contain most flow types that will need to be included. To give tenderers an idea of the extent of the coverage of the flows illustrated in this annex, they should refer to the table hereafter. The (almost) complete set of flows and data to be implemented will be made available to the contractor when the contract starts. Branches of social security Number of business flows Number of exchanges (SED messages in the flows) Pensions 5 10 Sickness Occupational diseases and accidents at work Unemployment benefits Family benefits Exchange of periods 2 3 Establishment of residence 3 8 Special non-contributory cash 3 6 benefits (Art 70) Determination of applicable 2 6 legislation (Art 17) Exemptions (Art 18a) 2 4 Additional information (Art 20) 4 7 Overpayment and cross-border recovery Other Business flows (not illustrated in this e) (a) ID Management 2 5 (b) Pre-retirement Benefits 2 5 (c) Death Benefits 2 5 ( d) Transfer of Claims 2 5 (e) Information available on applicable legislation 2 4 TOTAL Roughly speaking, the different social security sectors, such as sickness, pensions, etc., were studied by a separate group. Call for Tender VT/2008/019: Technical Specifications- Annex T1

104 As specified in annex A3, the table above is deemed correct with a margin of error of 7%. In addition, almost, but not all, flows counted on the table are illustrated in this annex (the bottom 5 rows are not, representing about 10% of the flows). In total, it is estimated that the flows that will be needed to complete the EESSI system and those that are not illustrated in this annex represent up to about 7+10 =17%. Note that the numbers above do include a type of flow that is not always explicitly shown in the diagrams below. It is the case of a flow that is explicit in the "pensions" chapter, namely the request for additional information (see scenario 2 under the pensions section below) 2. This is a typical case of a "horizontal flow", i.e. one that is useful in several sectors. Thus for instance for sickness, tenderers will see below 21 flows and 85 messages, but on the table above tenderers can read that we counted respectively 22 and 87. The outstanding flow is the one to request information and is exactly like flow "scenario 2" in the "pensions" section; the same applies to "occupational diseases", "unemployment", "family", "exchange of periods", "non-contributory benefits", "determination of applicable legislation", "exemptions", "additional information" and "overpayment". Now, the implementations of this flow in the different sectors will be very similar and one flow may be suitable for all sectors, thereby reducing the work required 3. Note also that the diagram labelled "art 34(2)" under "occupational diseases" has a main component of exchange of information. The flows are represented in a rough and inconsistent fashion. The ad hoc groups who worked on the flows have used different tools although they used a common broad syntax 4. However, by the time the contract starts, the Commission will be able to provide some flows 5 in a UML form; furthermore, during the contract term, the Commission, with the assistance of the contractor (see Technical Specifications, 4.9), will produce the complete data, message and flows in UML. At the same time, more flows will be added as ad hoc groups complete their work. The flows are between Competent Institutions (CIs). In some of the diagrams below, these are denoted as "countries"; this is because the EESSI system only implements the cross-border exchange of information and whenever two CI's exchange data within EESSI, they are in different countries. In some other diagrams, the notation is different again; tenderers will find an introductory legend right before the diagrams. In some diagrams, tenderers find reference to the "contact institution"; this is the institution that a private citizen has contacted, with a view to initiating a procedure (most often, a claim), thus starting the flow. Some of the arrows that represent sending of data from one CI to another are solid ( ); others are dashed (- - -). Tenderers should pay no attention to this distinction. It was made only for the benefit of the social security ad hoc group experts who needed to know whether or not the flows were explicitly stipulated in the regulations. In any case, EESSI will have to implement "solid" and "dashed" flows; both are important. Some ad hoc groups (e.g. "pensions") were parsimonious and collapsed similar flows together. Others (e.g. "sickness") kept similar flows separate and sometimes the only distinction between two flows is the SED message content. 2 This flow is also made explicit for the "determination of residence" case. 3 The reader could argue that other flows common to all sectors were only counted once; it happened that the exchange of information (pensions scenario 2) was counted several times when the table above was approved. 4 They also used different drafting styles and different acronyms. Readers should expect that, with each different PDF section, different acronyms apply; e.g. while above "IR" was "Institute of Residence", below it may mean "Implementing Regulation"; acronyms are announced at the start of each section. 5 Probably a sector or two; this will enable the contractor to start work already in complete, consistent areas. The transcription into UML of the flows in outstanding sectors will be completed later. Call for Tender VT/2008/019: Technical Specifications- Annex T1

105 Note that, as regards certain sectors, such as "family benefits", the data accompanying the flows are specified in this annex (as opposed to other sectors, such as "pensions", whose data is in annex T2). Generally speaking, this annex should be read jointly with annex T2. Some flows only differ in as much as the data contained in their SED messages differs. The data is presented in a separate annex (T2) because of document size and structure concerns. All these flows should be considered as tools that can be used by clerks in their day-to-day business in applying the Regulations. Clerks will need some freedom in using these tools, for instance by combining data in messages or messages in flows. The degree of freedom is to be discussed with the Commission and made compatible with the contractor's chosen architecture. Also note that in some flow diagrams, the acronym "MS" denotes "Member States". Throughout the technical specifications of this call-for-tender that acronym was avoided because of a potential conflict with "Microsoft", as in "MS-Office". However, since the diagrams were prepared by ad hoc groups and could not be adapted, some "MS" acronyms linger, for instance in the pensions data and the occupational diseases flows. The ad hoc groups derived the flows from the legislation. Hence, in their reports, they make references to regulation articles and even named SEDs after articles. In their final UML versions, SED could be given friendlier names. Overview of flow types The purpose of this section is to point out to the tenderers that, while the large majority of the flows are fairly straightforward, some are more complex. Nevertheless, tenderers should study all the flows to gain their own view on the complexity of the job that is requested. The most common flow types contain fixed SED message (i.e. the type of SED that one CI sends does not depend on the content of the SED received) and along fixed exchange patterns. For instance, scenarios 2.1 and 2.2 under sickness benefits are of this type; in fact, as flows, 2.1 and 2.2 are identical; they differ only as regards their title, and the title and content of the messages that they exchange. A slight variation occurs when the specific content of a SED can cause a flow to stop. As an example, flow 1.1 under sickness benefits foresees two fixed exchanges, namely the "Request for Information" and the "Information", and then, if the latter is positive, there is a further exchange with "Notification of Registration" and a last SED message with "Confirmation or Dispute". However, if the "Information" is negative and does not allow the registration of the claimant, the flows stops at that second SED message. The case of the first Pensions flow (labelled "Art 45-4 "), is more complex. Firstly, there are two (there could be several) counterparty countries. This happens when the claimant has worked in several EU countries and wishes to cumulate the rights acquired in each one of them. The contact CI (the competent institution that the worker has contacted with a request for a pension) has to send requests for information on the claimant's pension contribution periods to the CIs of other countries. To add to the complexity, the request is not always sent in a single SED message. Since the necessary data is complex and often difficult to obtain, the contact institution may start sending part of it, thus initiating the claim. As the contact institution finds more data on the claimant, it will send more SED messages to their counterparty CIs. In the meantime one or more or all of the counterparty CIs may find that the data received so far is sufficient to process the claim and may reply, even before the contact institution completes its sending. Other counterparty CIs may have to wait until they receive Call for Tender VT/2008/019: Technical Specifications- Annex T1

106 all the data required. At any stage of the process, the counterparty CIs may send the contact CI a request for additional information. In the case of Unemployment Benefit, under Art 55-4 scenario 5, we find a different pattern. Here there is a CI that sends a SED to a counterparty CI to express the wish to be informed periodically of a claimant's situation. This triggers a periodic sending from the counterparty CI to the contact CI. The period is currently 1 month. Hence, this is the case of a message that triggers several other messages, to be sent at specific times. Note that the expert group members have not created a procedure to stop the sending; this may have to be discussed and prepared, and is a potential gap in the flow descriptions. In some cases the ad hoc groups have included "acknowledgment messages". This could be turned into a general functionality for acknowledgment, to be made possible against any message and used whenever required/suitable. More generally experts have sometimes specified flows or flow actions that have a more general application than their own subsectors. The Commission will be able to assist the contractor and assess the opportunity to extend their applicability and ensuring that the EESSI protocol is consistent. Note that, even when a business flow has ended its foreseen exchanges, it is still possible that the Competent Institutions (CI) still need to exchange information. This is explicitly indicated in flow 17 under "unemployment benefits". They will do so mainly using free-text annexes. Nevertheless, it will be important that at least the SED envelope is used, which will give the CIs the opportunity to keep complete files via the claim case numbers in the envelopes. Call for Tender VT/2008/019: Technical Specifications- Annex T1

107 Pensions The expert group identified five business flows, hereafter called scenarios. These flows are also incorporated in the excel tool that shows the data, available at in which the user can see for each Member State and type of pension, which data is needed for each of the messages to be sent by a pension Competent Institution in the competent state (e.g., decision on a pension claim, withdrawal of benefit etc). The ad-hoc group (AHG) identified the following scenarios in which data need to be exchanged between the Member States: 1. Claim for a pension by the claimant with the contact institution. 2. Request for more information (to complete the pre-defined data or request for data which is only required in exceptional cases). The SED could take the form of a detailed sheet for each Member State or of "free text". (note, this scenario/flow is also applied in other sectors) 3. Withdrawal of a pension claim by the claimant. 4. Notification of a pension decision (this may concern the award or rejection of a pension claim (ref. scenario 1), or the recalculation, withdrawal, or suspension of pension benefit) 5. Exchange of child raising periods. In the identification of the flows, the expert group has taken into account the following: 1. The AHG has not identified cases in which a formal acknowledgement of receipt is required. It is expected that clerk sending a SED message can always request a standard acknowledgement of receipt. 2. The flows do not include horizontal flows as for example medical reports, birth certificates or other documentation required by the competent state. 3. Considering that the data flows concerning the situations in which the competent state issues a decision are the same, these are covered by one scenario (see scenario 4). The SED to be developed should allow some options to indicate which decision is concerned. 4. Separate flows are introduced on the exchange of data on child raising periods. 1. SCENARIOS Between the implementing bodies the exchange of the required information is analysed by using scenarios. Each scenario represents a bundle of flows with similar mechanisms. Tenderers/contractor can consider these scenarios as business flows. There are five scenarios/flows. Claiming for pension Requesting for/ Replying with more information Withdrawal of the Pension Claim Notification of the Pension Decision

108 Child Raising Periods 2. EXPLANATIONS FOR SCENARIOS AND FLOWS Scenario 1 Pension claim The scenario presents the basic situation when a pension claim is notified by the contact institution. The scenario also concerns the situation when the contact institution sends all documents of the person concerned to the institution with which he/she was previously insured in case the claimant is not entitled to an A-type pension in the Member State where the invalidity occurred. The data flows are the same as in the basic situation when the pension is claimed. Considering that each SED should allow for the possibility to attach a supporting document (Task Force (TF) Recommendations, CASSTM note 335/07, point 2(a)), AHG on Pensions has not identified separate business-flows for the exchange of documents, such as medical reports. For the processing of the pension claim supporting documents normally required are medical reports, birth certificates, work-books and employment certificates. On the basis of the Recommendations of the TF, it was concluded that in the pension sector there is no need for a formal acknowledgement of receipt other than a technical acknowledgement. The TF also recommends that horizontal business flows are introduced for the transfer of documents submitted by a person to an institution of not a competent Member State. The AHG on Pensions therefore only refers to that horizontal flow without identifying closer this flow. 2

109 F1.1 Pension Claim The entire data-set needed in the pension application process has been pre-defined. The data to be exchanged have been sorted in relation to the needs of each Member State so that it could award the pension. The data are also divided on the basis of a type of pension (i.e. old age, survivors, and invalidity). The contact institution shall without delay send claims for benefits and all documents which it has available etc. to all the institutions in question. F 1.2 Rest of the Pension claim It must be possible for the contact institution to send the data concerning the pension application in more than one flow i.e. complement the first flow. In practice, a Member State very often cannot provide all the information needed by the other Member States at once. The contact institution must also communicate to the receiving Member States that it will not send any further information unless required or lists which information will be sent at a later date. When the information is provided in complementary flows (Rest of the Pension Claim) there is a need to decide, whether all the former information is provided with the new information or only the new information. In case the old information has changed it must of course be provided once more. This is a highly important issue with regard to the possibilities that the national data systems shall offer. F 1.3 Claimant s report on insurance history The data concerning insurance history of a claimant is based on the claimant's own notification. This data set must be communicated to all other Member States involved into a process as soon as possible. F 1.4 Insurance Periods As mentioned above under point F1.1 Pension Claim, the entire data-set needed in the pension application process has been pre-defined. The data to be exchanged have been sorted in relation to the needs of each Member State so that it could award the pension. The data are also divided on the basis of a type of pension (i.e old age, survivors, and invalidity). However, with regard to the exchange of insurance periods it has not been possible to follow this principle due to the fact that the Administrative Commission which has been asked by the Group to clarify the legal situation as to the different types of data to be exchanged, has not yet been in a position to provide the Group with the required clarifications. When there are three or more institutions involved in a process, information concerning insurance periods is exchanged directly between the institutions and not via the contact institution. Insurance periods can be sent to other institutions in question at the same time with the data concerning the pension application or at a later date, as soon as possible. Information to be sent at a later date must be indicated. 3

110 Scenario 2 Pension Claim, Request/Reply: more information This scenario presents the situation when the contact institution or competent institution needs additional data from the other Member State. In the Implementing Regulation there are no explicit rules concerning this flow. A request may concern e.g. - request to complete the pension claim (to complete the predefined data as mentioned above under F 1.1) - request for insurance periods - request for additional information e.g. the pre-defined data concerning the pension claim are not sufficient to the competent institution (the claim may concern a specific article in the pension legislation only applicable to few people.) This scenario also includes the situation when a Member State that awards an A-type invalidity pension requests insurance periods from the other Member States when aggregation of periods is applied. Considering the horizontal flow on any additional information which might be necessary the expert group on Pensions agreed that these data could, for example, take place by using a horizontal flow as referred to in the recommendations of the Task Force. However, it must be possible for the competent institution to list from the data-sets that have been determined which data it requests. F 2.7 and 2.8 Request/Reply: complement the pension claim /additional information The competent institution may need more data than what the contact institution has sent to it. The first situation mirrors that of scenario 1, in which a pension claim can be dealt with once all the pre-defined data is provided (in one or more flows). In this situation the same SED, containing the pre-defined data, is used as a shopping-list by the competent institution in it its request for more data to indicate which data is essential to start the process of assessing the pension claim. The contact institution shall reply by using the predefined data-sets. In the second situation, it is not clear in advance which additional data is missing. This flow will therefore have a more general format and should allow the institution to list in "free text" the additional data needed. This data exchange could, for example, take place by using a horizontal flow as referred to in the recommendations of the Task Force. If necessary, the contact institution requests the data needed from the claimant. The request and reply may also concern the insurance periods or the other missing documents. The situation may also be the other way round when the contact institution needs more data from the competent institution. Scenario 3 Withdrawal of a Pension Claim The scenario presents the situation where the claimant withdraws a claim for benefits. 4

111 F 3.9 Withdrawal of a pension claim When the claimant notifies that she/he wants to withdraw a claim for benefit/benefits, the contact institution or competent institution notifies the other institutions involved in the process. The withdrawal may concern the pension claim of any of the institutions involved in the pension process, i.e. the withdrawal may concern the pension claim of one Member States or all Member States. All Member States involved in the process need information about the withdrawal of the claim. In the Implementing Regulation there are no explicit rules concerning this flow. Scenario 4 Notification of the Pension Decisions The scenario presents the situation when a decision concerning the pension benefit is made. Consequently the decision is notified to the other institutions involved in the process. The decision may cover a decision about pension (grant or rejection) new calculation of the pension withdrawal of the pension benefit Suspension of the pension benefit. F 4.10 Pension Decision Each of the institutions in question shall notify the claimant of a decision taken. Each of the competent institutions shall also send the decision taken to the contact institution and the other institutions. When two or more Member States are involved in the process, it must be noticed that the competent institution shall notify the other institutions in question of its decisions directly and not via the contact institution. The data concerning a new calculation is the same as the data concerning the decision. F 4.11 Summary Note The contact institution shall send to the claimant and other institutions in question a summary of decisions once the contact institution has been notified of all decisions. Scenario 5 Child raising periods: The contact institution is not the competent Member State To be able to implement Article 44 of the Implementing Regulation the data concerning child raising periods must be communicated between those Member States that acknowledge these periods as insurance periods under their own legislation. That data are required to identify the competent state and the secondary competence. Information concerning the child raising period should in the first place be determined during the 5

112 working life of the person concerned. The scenario concerns the situation when the contact institution does not recognize the child raising periods and it is not the competent state to award pension for the child raising periods. The scenario should only be for retrospectively or retroactively establishing the child raising period for periods before the new legislation was adopted. It may also concern the situation when for some other reason it is not clear which Member State is competent to award pension for the child raising period. F 5.14 Child raising periods When on the basis of the information received on the claimant's report on insurance history) or otherwise the contact institution notices that the claimant has raised child(ren) and this Member State is not the competent state, the data concerning the child raising periods must be communicated between all institutions involved into a pension application process. In the Implementing Regulation there are no explicit rules concerning this flow. 3. TABLE OF SEDS BY SCENARIOS The flows, specified according to the function, make up an administrative mechanism that in its electronic appearance implements the needs of data exchange between the Member States. An individual flow is an instance of one SED (Structured Electronic Document). The same SED may be applied in several different functional flows. E.g. the SED "Request" covers different needs. This can be a request for more data to process a pension claim or a request for insurance periods or something else. All the flows are covered by 10 SEDs and by one unstructured document. The SEDs have common characteristics e.g. claimant's details, receiver, data provider and the functional data. The main interest of the expert group on Pensions is the functional data. At this stage the SEDs have been considered to be preliminary. Later onwards, during the forthcoming definition work, the SEDs have to be designed and constructed in line with the industrial standards and requirements. A trigger does not appear in this approach. 6

113 Table of SEDs by scenarios Numb er SED Abbr eviati on Using scenar io Remarks 1 Pension claim PCL S1 PCL may be complete or incomplete. 2 Rest of the pension claim PCR S1 PCR will complete an incomplete PCL. 3 Claimant's report on insurance history CRH S1 The document may be finished by the claimant or by the pension institution. 4 Insurance periods IPE S1 Only one SED for a Member State, IPE may be preliminary or final. 9 Withdrawal WDL S3 WDL means withdrawal of a pension claim. 10 Pension decision DEC S4 A DEC may concern - pension award - new calculation of a pension - withdrawal of a pension - suspension of a pension 11 Summary note SUM S4 Compilation of decisions. 7 Request REQ S2 A request may concern - request to complement the pension claim (PCL) - request for insurance periods - Additional information e.g. PCL is not sufficient to the competent institution. Besides fixed questions a request (REQ) may include an issue given in free text. Besides fixed questions a request (REQ) may include an issue given in free text. 8 Reply REP S2 REP may concern: -more data (additional) for the pension claim --anything else REP will complete PCL and PCR and a former REP. The content of the additional data corresponds to PCL and PCR. REP may involve free text. 14 Child raising periods CRP S5 CRP flow clarifies which Member State is responsible to 7

114 Attachment ATM S1 S2 take into account child raising periods. This flow is not given by the implementing regulation. ATM is an unstructured supporting document that will be provided as an attachment to a SED. ATM may be - Medical report - Workbook - Employment certificate - Birth certificate 8

115 Work flows in the pension field Pension Sector Articles 45 (4), 46 (1), 47 (4-5) Imp.Reg Scenario 1: Pension Claim Competent Institution EESSI Contact Institution Institution of the place of residence MS B MS C F2.4 Insurance Periods F1.1 Pension claim F1.2 Rest of the pension claim F1.3 Claimant s report on insurance history F1.4 Insurance Periods MS A Pension Claim F1.4 Insurance Periods F1.1 Pension claim Flow explicitly stipulated in F1.2 Rest of the pension claim the Reg. F1.3 Claimant s report on Flow NOT insurance history explicitly stipulated in F1.4 Insurance Periods the Reg. F1.4 Insurance Periods Trigger 1 Note! Each SED should allow for the possibility to attach a supporting document (e.g medical report) key Pension Sector Articles 46 (1), 47 (4) Imp.Reg Scenario 2: Request/Reply: more information Competent Institution EESSI Contact Institution F2.7 Request: complement the pension claim / additional information F2.8 Reply: complement the pension claim / additional information MS B MS C etc. F2.7 Request: complement the pension claim / additional information F2.8 Reply: complement the pension claim / additional information MS A key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 1

116 Pension Sector Articles 46 (3) Imp.Reg Scenario 3: Withdrawal of a Pension Claim Competent Institution EESSI Contact Institution Claimant withdraws the pension claim Claimant withdraws the pension claim MS B Claimant withdraws the pension claim MS C F3. 9 Withdrawal of a pension claim F3. 9 Withdrawal of a pension claim F3. 9 Withdrawal of a pension claim F3.9 Withdrawal of a pension claim F3. 9 Withdrawal of a pension claim MS A key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 3 Pension Sector Articles 47(6),48(1), 51(2) Imp.Reg Scenario 4: Notification of the Pension Decisions Competent Institution EESSI Contact Institution F4.10 Pension decision MS B F4.10 Pension decision MS C F5.11Pension decision F4.11 Summary note F4.10 Pension decision F4.10 Pension decision F4.11 Summary note MS A key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 4 2

117 Pension Sector Article 44 Imp.Reg Scenario 5: Child raising periods: The contact institution is not the competent MS Competent Institution EESSI Contact Institution Pension Claim F5.14 Child raising periods MS B MS C F5.14 Child raising periods F5.14 Child raising periods F5.14 Child raising periods F5.14 Child raising periods MS A key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 1 3

118 Sickness (Health Insurance) Note, the following flow should be added to the flows that follow, in diagrammatic fashion. Since this flow could be used in other sectors than sickness, it should be made available to all clerks. In addition, this flow encompasses the role of flow 27(5) (with messages through ). Hence, the latter flow can be left out (it is in because what follows is the set of flows that were formally approved). In the count of the flow number (see the table at the top of this annexe) we counted for "sickness" the flow below, plus 20 of the 21 diagrams that follow (i.e. all except 27(5)), plus one flow for exchange of information (similar to "pensions", scenario 2), for a total of 22. Ad table D, 2 claims for costs for medical reports Table D2 is to be used for reimbursement of costs for medical checks. There are no financial provisions for this flow. The expert Group suggests a special SED for this financial flow as fewer data are needed than in the flows concerning benefits in kind and as claims for cost for medical checks must be sent in a file other than the one concerning benefits in kind. The SEDs concerning costs for medical checks may be sent separately or in bulk. These SEDs should be sent with the global claim note, flow A. The flows in D2 are suggested flows to cover Article 82, cf. TF 098/07.: Trigger: An institution needs medical or administrative examinations of a person staying or residing in another Member State Institution in Member State A Institution in place of stay or residence in Member State B Request for examination or check Information on costs exceeding a specified limit Decision if examination or check has to be made or not Results of examination or check Claim of reimbursement Acknowledgement of receipt Information on payment Contestation Information requested Contestation accepted Information on final settlement

119 Acknowledgement Ad table D 3 Contestation codes. The list consists of codes to be used in row 54 in Table D.1.

120 CASSTM 013/08 Annex 1 Article 24 Residence in a Member State other than the competent Member State Scenario 1.1: Person without entitlement document Competent institution EESSI Institution of the place of residence Request for information concerning the right of the insured person and/or his/her family members to benefits in kind Me mbe r Stat e A Information (entitled or not) concerning entitlement of the insured person and/or his/her family members to benefits in kind Notification of registration Me mbe r Stat e B Person without entitlement document Dispute of date of registration Scenario 1.2.1: Person with entitlement document information certifying rights is sent directly to the institution of the place of residence Scenario 1.2.2: Person with entitlement document information certifying rights is issued to the person concerned Competent institution EESSI Institution of the place of residence Sc Information of entitlement (or non Me mbe r Stat e A Notification of (non)/registration Me mbe r Stat e B Sc Person with entitlement document Dispute of date of registration 1

121 Scenario 2.1: Change or cancellation of entitlement document Scenario 2.2: Change or cancellation of registration Competent institution EESSI Institution of the place of residence Sc. 2.1 Me mbe r Stat e A Change or cancellation of entitlement document Confirmation or contestation of change or cancellation Change or cancellation of registration Me mbe r Stat e B Sc Confirmation or dispute of change or cancellation 2

122 Article 25 Stay in a Member State other than the competent Member State Scenario 1: Person without entitlement document Competent institution EESSI Institution of the place of stay Request for information concerning the right of the person concerned to benefits in kind (nearly similar to 24.1) Me mbe r Stat e A Information concerning entitlement (entitled or not) of the person concerned to benefits in kind Me mbe r Stat e B Person without entitlement document Scenario 2: Reimbursement of costs of the benefits in kind by competent institution (art. 25(6)) Competent institution EESSI Institution of the place of stay (via the Liaison Body) Request for information concerning rates or amounts which would have been subject to reimbursement Me mbe r Stat e A Information concerning: rates or amounts which would have been subject to reimbursement or information that no rates exist (26,7a) or there is no reimbursement Me mbe r Stat e B 3

123 Article 26 Scheduled treatment Scenario x: Institution of residence seeks information as to if a specific benefit in kind is covered by the social security provisions in the Member State in which scheduled treatment is wanted. Competent institution /institution of residence EESSI Institution of the place of stay Request for information Me mbe r Stat e A Information specific benefit in kind is covered by the social security Me mbe r Stat e B Scenario 1.1: Situation when an insured person does not reside in the competent Member State authorisation procedure 1 Competent institution EESSI Institution of the place of residence Me mbe r Stat e A 26(4) Request for authorisation with statement that conditions stated in Article 20(2) second sentence are / are not fulfilled Request for information (E001 situation) Information (E001 situation) ((information of) medical examination required) (result of medical examination) Me mbe r Stat e B Information of authorisation or refusal for scheduled treatment 1 The flows suggested in connection with 26(4) is information to the IR that the CI has required medical information from a doctor 4

124 Scenario 1.2: Situation when an insured person does not reside in the competent Member State authorisation procedure when the insured person is in need of an urgent vitally necessary treatment (Art. 26(3)) Competent institution EESSI Institution of the place of stay Notification of authorisation Institution of the place of residence Me mbe r Stat e A Notification of receipt MS B Authorisation is granted on behalf of competent institution Notification of receipt and instruction to Institution of place of stay that the bill can be sent straight to the Competent Institution via the liaison bodies (i.e. not via the member State of Residence) Scenario 2: Extension of existing authorisation (Art. 26(4a)) Competent institution EESSI Institution of the place of stay Information that appears medically appropriate to supplement a treatment Me mbe r Stat e A Acknowledgement Authorisation or refusal Me mbe r Stat e B 5

125 Scenario 3: Reimbursement of costs of the benefits in kind by competent institution (Art.26(5)) Competent institution EESSI Institution of the place of stay (via Liaison Body) Me mbe r Stat e A Request for information concerning rates or amounts which (would) have been subject to reimbursement Information concerning rates or amounts which (would) have been subject to reimbursement Me mbe r Stat e B 6

126 Article 27 Cash benefits relating to incapacity for work in the event of stay or residence in a Member State other than the competent Member State Scenario 1: Notification of incapacity for work when the certificate related to incapacity is not issued by doctor (27(3)) Competent institution EESSI Institution of the place of residence or stay Application for cash benefits with Certificate related to incapacity for work if necessary Me mbe r Stat e A Me mbe r Stat e B Scenario 2: Procedure to be followed when any administrative checks or medical examinations are required (27(5)) Competent institution EESSI Institution of the place of residence or stay Request for any administrative checks or medical examinations Me mbe r Stat e A Information about costs of medical examination Approval for medical examination MS MS Me mbe B r Stat e B Report of administrative checks or medical examinations 7

127 Scenario 3: Information on payment of cash benefits or on refusal of cash benefits (27(8) and (10)) Competent institution EESSI Institution of the place of residence or stay Notification Notification of refusal of payment the cash (if benefits necessary) or refusal of cash benefits MS Me A mbe r Stat e A Information of end of incapacity MS Me mbe B r Stat e B 8

128 Article 27a Long-term care benefits in cash in the event of stay or residence in a Member State other than the competent Member State Scenario 1: Notification of long-term care benefits in cash (27a(1)) Competent institution EESSI Institution of the place of stay or residence Notification application for long-term care benefits (where necessary) Me mbe r Stat e A Acknowledgement Me mbe r Stat e B Scenario 2: Procedure to be followed when any medical examinations are required(27a (2) and (3)) Competent institution EESSI Institution of the place of stay or residence Request for examination of condition including all necessary information Me mbe r Stat e A Result of examinations Me mbe r Stat e B 9

129 Article 28 Former frontier worker goes for treatment in former Member State of activity which is no longer competent Member State Scenario 1: Person applying for document certifying rights from the competent institution Competent institution EESSI Institution of the last state of activity Request for information concerning the person s former status as frontier worker Me mbe r Stat e A Information concerning former status as frontier worker Me mbe r Stat e B Information concerning entitlement (entitled or not) of the person concerned to benefits in kind Scenario 2: Person with document certifying rights (see business flow of Art 25) Article 30(2) Application of Article 34 of the basic Regulation Competent institution EESSI Institution of the place of residence or stay Information about payment of long-term cash benefits Me mbe MS r Stat A e A a - Acknowledgement of receipt of the information Information about long-term benefits in kind and the rate of reimbursement b - Acknowledgement of receipt of the information Me mbe MS B r Stat e B Information on change in the rate of reimbursement/change in the national legislation or end of payment of long-term benefits 10

130 Actual expenditure (Article 65, 66(1) and 67) Liaison Body of Competent Institution (debtor) EESSI Liaison Body of Institution of residence or stay (creditor) Claim Credit Note Me mbe r Stat e A Acknowledgement of receipt Information on down payments Information on payment and/or contestation Me mbe r Stat e B Information requested or acceptance of contestation Information on final settlement Fixed amounts (Article 63, 65, 66 and 67) Liaison Body of Competent Institution (debtor) Liaison Body of Institution of residence (creditor) Inventory of months Me mbe r Stat e A Acceptation/refusal of the inventory of months or request for further investigation Information on down payments Reply: Information requested or acceptance of contestation Claim Me mbe r Stat e B Information on final settlement 11

131 Article (not in Regulation) for the Cross sectoral Ad Hoc Ad Hoc group Payment/Request for refund of actual cost/fixed amount paid (overpayment) Liaison Body of Competent Institution (debtor) Liaison Body of Institution of residence or stay (creditor) XX Request of refund of overpayment Me mbe r Stat e A XX Information of payment or refusal XX Information on refund of overpayment Me mbe r Stat e B Article 67 Interest on late payments Liaison Body of Competent Institution (debtor) Liaison Body of Institution of residence or stay (creditor) Claim for interests Information on payment or refusal Me mbe r Stat e A Information on payment Reply Me mbe r Stat e B 12

132 Occupational Diseases and Accidents at work In the diagrams below, please consider that the notation is as follows: IS denotes the State in which the Incident has taken place CI is the Contact Institution, i.e. the social security institution that the claimant has contacted with a view to filing their claim IR is the Institution in the state of Residence Other types of institutions are described in the diagrams. Note that diagram "Art 36(1)" has two possible configurations. Since the business flows are to be provided as tools, the contractor may consider simply providing the two configurations as separate flows.

133 Art. 34 (1) IR MS A = CI Cooperation between institutions ( ) 1st hypothesis : A is CI, B is State of residence and accident occurs in C, the person or employer send copy of the declaration through the CI. IS MS B = IR Sends a copy of the declaration Employer or person concerned address the declaration to the CI and need to send copy to the IS or IR Sends a copy of the declaration CASSTM 014/08 Annex 2 1

134 Art. 34 (1) IR MS A = CI Cooperation between institutions ( ) 2nd hypothesis : Employer or person claim to the institution which is not competent, but according to Art. 81 has to forward the declaration and the copy. IS MS B = IR Sends declaration Sends a copy of the declaration Employer or Person Concerned goes to an IS which is not CI

135 Art. 34 (1) IR MS A = CI Cooperation between institutions ( ) 3rd hypothesis : employer or person concerned claim to the institution which is not competent, but according to Art. 81 has to forward the declaration and the copy. IS MS B = IR Sends the declaration Sends a copy of the declaration Employer or Person Concerned goes to an IR which is not CI

136 Art. 34 (2) IR MS A = CI Cooperation between institutions ( ) IS Notify of medical certificate Request for more information Sends further information Request of the person or of IS

137 Art. 34(4) IR CI Cooperation between institutions ( ) IS/IR Sends detailed report accompanied by medical certificates (all information listed in paragraph 4) acknowledgement Information of the end of treatment

138 Art. 34(5) IR CI Cooperation between institutions ( ) IS / IR Request for a decision Notify of the decision setting the date for the recovery or stabilisation of injuries and, where appropriate, the decision concerning the granting of a pension Request of IS or IR

139 Art. 35 (1) IR CI Contestation of the occupational nature of IS or IR Notify of contestation acknowledgement CI contests application

140 Art. 35 (2) IR Contestation of the occupational nature of CI IS or IR Notify of final decision acknowledgement Final decision of CI has been taken

141 Art. 36(1) al 1 IR Procedure in the event of exposure IS IR CI of the last MS under the legislation of which the victim pursued an activity likely to cause the said disease Sends declaration of occupational disease OR IS gets the information about occupational disease Sends declaration of occupational disease Sends declaration of occupational disease

142 Art. 36(1) al 2 IR Procedure in the event of exposure CI of the last MS under the legislation of which the victim pursued an activity likely to cause the said disease CI of another MS under the legislation of which the victim pursued an activity likely to cause the said disease (IS, IR or another MS) Sends declaration and accompanying certificates Supposed CI receives declaration and disagrees

143 Art. 36(2)IR Procedure in the event of exposure CI of the last MS under the legislation of which the victim pursued an activity likely to cause the said disease CI of the previous MS under the legislation of which the victim pursued an activity likely to cause the said disease (IS, IR or another MS) Sends documents listed in 36(2)) CI notices that conditions are not fulfilled CI notices that conditions are not fulfilled

144 Art. 37 (1) IR Exchange of information between MS A Institution to which the declaration was sent Notify of appeal Subsequently : Notify of final decision Appeal of person

145 Art. 37 (2) IR Exchange of information between MS A Institution to which the declaration was sent Request for information to determine the amounts Sends information advances payment Request for information Person is entitledtof provisional benefit Sends information reimbursement of advances payment

146 Art. 38 IR MS A Aggravation of an occupational disease MS B previously CI Request for any information Sends information Claim of person

147 Art. 39 IR MS A Assessment of the degree of incapacity MS B previously CI Request for information Sends information information on another accident or change in degree of incapacity

148 Art. 40 (1) IR Submission and investigation of claims for pensions Person applies to MS of Residence IR CI Sends claim, accompanied by necessary documents direct acknowledgement request of the person

149 Art. 40 (2) 2nd sentence IR Submission and investigation of claims for pensions IR Person applies to MS of Residence CI LB IR Sends copy of the decision decision of CI is taken LB CI OR

150 Unemployment Benefits In addition to the flows that are specific to the processing of Unemployment Benefit claims, which you will find hereafter, two general business flows were identified, that might be applicable in other sectors: Delay notification (see template no. 20) This business flow covers situations where the requested institution assumes that it will take some time to process the request for data (eg because it will have to contact the employer or investigate the case). In such cases, there should be an optional possibility for the requested institution to communicate the estimated delay to the requesting institution. This should prevent unnecessary chasing up of the request, and give both requesting institutions and claimants an idea of the time it will take to be processed. Contesting the data received or request for further clarification (see template no. 21) This business flow should give the requesting institution the possibility, after it receives the required data, to contest the content of the data provided or to ask the other institution to further clarify some of the information in question. This would therefore be an additional communication between the institutions concerned following the initial data exchange and could be useful in cases where the data provided conflicts with the data of the other Member State, or where the claimant declares the data provided to be incorrect. It is essential that institutions should be able to print out documents that are to be exchanged under EESSI, and also that the documents will be able to be stored electronically in institutions own systems.

151 UNEMPLOYMENT BENEFITS Business flows A business flow is a scenario in which two Member States exchange some data in order to establish entitlement to Unemployment Benefits (UB). Exchanges between a Member State and the person who is entitled to unemployment benefit were not defined, except for flow 4, as will be explained further. The ad-hoc group decided to give the possibility to attach a document to each message exchanged. Hence, the contractor should make it possible to attach enclosures to any SED message (note: this applies to all SED messages in all sectors) On basis of the Articles of Regulation 883/2004 and and 69 of new implementing Regulation, 19 business flows have been defined by the group: 1. Claimant resident in competent state but previously insured in another 2. Claimant resident in competent state but previously employed in another 3. Claimant resident in competent state but family resident in another 4. The unemployed person requests a document from the competent institution certifying that he/she retains entitlement to benefits 5. The unemployed person registers with the assisting institution without having the document 6. The unemployed person registers with the assisting institution 7. The assisting institution comes to know about circumstances likely to affect the entitlement to benefits 8. The competent institution wants information concerning the follow-up of the unemployed person s situation note, the reply message is periodical! 9. The unemployed person returns to the competent state before the period granted to search for work ends, and the competent institution has come to know that the unemployed person did not inform the assisting institution about his/her return to the competent state 10. The competent institution extends the period granted to the unemployed person to export their unemployment benefits 11. The entitlement to benefits terminates during the three (to six) month export period for any reason and the termination date is different from the previously certified date 12. Person makes himself/herself available to the employment services in the Member State of residence 13. Person takes a supplementary step- he/she makes himself/herself available to the employment services of the Member State in which he/she pursued his/her last activity 14. Person who has been provided UB at the expense of the competent institution of the Member State to whose legislation he/she was last subject (Member State of the last activity) has decided to return to the Member State of residence 15. Reimbursement between Member States => Full acceptance of the request 16. Reimbursement between Member States => Request for reimbursement is not accepted or is partially accepted 17. Request for reimbursement is not accepted or is partially accepted, clarification of disputes and objections 18. Reimbursement between Member States => Possibility of charging interest 19. Reimbursement between Member States => Closing flow.

152 Business flows The business flows (13 and 18) have been slightly amended since the version which was approved by the Task Force. Unemployment Benefits 1 Articles 61(1) and 61(2) Aggregation of periods of insurance, employment or self employment Scenario: Customer resident in Competent State but previously insured in another Institution of former insurance EESSI Competent Institution Request under Art. 54 (1) made by the claimant (*) Notification of a benefit claim Request for insurance record (Article 54 of implementing regulation) Message 1.1 Benefit Claim MS B MS C etc. Notification of insurance record Message 1.2 MS A key Issue of the special document under Art. 54 (1) Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. * Obligation of the institution involved under Article 54 (1) of the implementing Regulation to issue a document specifying the periods completed under the legislation it applies (= printed SED) Trigger Unemployment Benefits 2 Institution of last employment Articles 62(3) and 54(1) Calculation of benefits based upon salary Scenario: Customer resident in Competent State but previously employed in another EESSI Competent Institution Notification of a benefit claim Request for salary or professional income (Article 54 of implementing regulation) Benefit Claim Message 2.1 MS B Notification of salary or professional income MS A key Message 2.2 Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 2

153 Unemployment Benefits 3 Institution of the state of residence of family members Article 62 Calculation of benefits varies with the number of members of the family Scenario: Customer resident in Competent State but family resident in another EESSI Competent Institution Notification of a benefit claim Request for details of dependent family members (Article 54(3) of implementing regulation) Benefit Claim Message 3.1 MS B MS C etc. Notification of details of dependent family members Message 3.2 MS A key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Sector - 4 assisting institution Article 55 (1) Impl. Reg.: request for the document that certifies the export of unemployment benefits Scenario 1: the unemployed person requests a document from the competent institution certifying that he/she retains entitlement to benefits competent EESSI institution Request under Art. 55 No. 1 made by the claimant (*) MS B *) Obligation of the competent institution under Article 55 (1) of the implementation Regulation to issue a document certifying the entitlement to benefits under the conditions laid down in Art. 64 (1) b) of the basic Regulation (= printed SED). In exceptional cases the same document is exchanged via EESSI between the institutions of MS S and MS B under Art. 55 (2) of the implementing Regulation (compare scenario 1). MS A Issue of the special document under Art. 55 No. 1 Impl. Reg. Unemployment Sector - 5 competent institution Article 55 (2) Impl. Reg.: request for the document that certifies the export of unemployment benefits Scenario 2: the unemployed person registers with the unemployment services of the assisting institution without having the document EESSI assisting Message 5.1 request for the document certifying that the unemployed person retains entitlement to benefits under the conditions of Art. 64 Reg. 883/2004 registration without document certifying rights MS A document certifying above mentioned entitlement Message 5.2 MS B key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 3

154 Unemployment Sector - 6 competent institution Article 55 (4) Impl. Reg.: notification of registration Scenario 3: the unemployed person registers with the unemployment services of the assisting institution assisting EESSI Message 6.1 information of the date of registration and of the new address of the unemployed person registration with or without document certifying rights MS A MS B key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Sector - 7 Article 55 (4) Impl. Reg.: procedure if circumstances likely to affect the entitlement to benefits occur Scenario 4: the assisting institution comes to know about circumstances likely to affect the entitlement to benefits competent institution EESSI assisting Message 7.1 information without delay about the relevant information concerning the circumstances likely to affect the entitlement to benefits circumstance s likely to affect the entitlement to benefits key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger MS A Message 7.2 information about the effect of the circumstances to the entitlement to benefits, only 1. if requested by MS B and 2. if the information is sent before the period granted to retain the entitlement to benefits under Art. 64 (1) c) Reg. 883/04 is finished MS B document sent (by adequate means) to the unemployed person containing the information given to MS A (*) * Obligation of the assisting institution under Art. 55 No. 4 of the implementing Regulation to send the document (= printed SED) containing the relevant information not only to the competent institution but also to the person concerned. Unemployment Sector - 8 assisting institution Article 55 (4) Impl. Reg.: notification about the follow-up of the unemployed person s situation Scenario 5: the competent institution wants information concerning the follow-up of the unemployed person s situation EESSI competent MS B Message 8.1 request for relevant information concerning the follow-up of the unemployed person s situation Message 8.2 etc. on a monthly basis: information concerning the follow-up of the unemployed person s situation MS A the competent institution wants information concerning the follow up of the unemployed person s situation key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 4

155 Unemployment Sector - 9 assisting institution Article 64 Reg. 883/04 (not explicitly stipulated): procedure on the return of the unemployed person to the competent state Scenario 6: the unemployed person returns to the competent state before the period granted to search for work ends, and the competent institution has come to know that the unemployed person did not inform the assisting institution about his/her return to the competent state EESSI competent Message 9.1 notification of the returning of the unemployed person (and the end of the entitlement to export the unemployment benefits under the conditions laid down in Art. 64 Reg. 883/04) registration with the competent institution MS B MS A key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Sector - 10 assisting institution Article 64 Reg. 883/04 (not explicitly stipulated): procedure if the period granted to the unemployed person to export their unemployment benefits is extended Scenario 7: the competent institution extends the period granted to the unemployed person to export their unemployment benefits EESSI competent Message 10.1 notification of the extending of the period granted to the unemployed person to export their unemployment benefits decision of the competent institution MS B MS A key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Sector - 11 assisting institution Article 64 Reg. 883/04 (not explicitly stipulated): termination of the entitlement to benefits during the three (to six) month export period pursuant to Art. 64 (1) c) Reg. 883/2004 Scenario 8: the entitlement to benefits terminates during the three (to six) month export period for any reason and the termination date is different from the previously certified date competent EESSI Message 11.1 notification of the end of the entitlement to unemployment benefits as soon as the entitlement terminates the entitlement to benefits is terminated MS B (the assisting institution can stop carrying out checks) MS A key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 5

156 Unemployment Benefits 12 Scenario 1: Art.65(2) first sentence of the Reg. 883/2004 Person makes himself/herself available to the employment services in the Member State of residence Institution of the state of the last activity EESSI Institution of the state of residence Request for the data necessary for calculating the UB-Art. 61 and 62 shall apply Person registers only in the state of residence Message 12.1 MS A Data provided Message 12.2 MS B key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Benefits 13 Scenario 2: Art.65(2) second sentence of Reg. 883/2004 Person takes a supplementary step- he/she makes himself/herself available to the employment services of the Member State in which he/she pursued his/her last activity Institution of the state of the last activity EESSI Institution of the state of residence Request for information concerning the unemployed person s registration and search for employment in MS B- Art last sentence Person registers in the state of residence Message 13.1 MS B sends the information requested Person registers also in the state of the last activity MS A Request for information on the jobseeking activities in the MS of the last activity Message 13.3 Message 13.2 Message 13.4 Upon request - information on jobseeking activities in the MS of the last activity MS B key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Benefits 14 Institution of the state of the last activity Scenario 3: Art.65 (5) (b) of Reg. 883/2004, Art.56 (3) of the Implementing Reg. Person who has been provided UB at the expense of the competent institution of the MS to whose legislation he/she was last subject (MS of the last acitivity) has decided to return to the MS of residence EESSI Institution of the state of residence Person was provided UB at the expense of the institution he/she was last subject MS A Message 14.1 Request for the information on the entitlement to UB under Art. 64 and the period of receiving UB in MS A MS A sends the information requested Message 14.2 MS B Person returns to the state of residence and claims UB there key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 6

157 Unemployment Benefits 15 Liaison body State of the last activity Scenario 1: Art.65(6) and 65(7) of Reg. 883/2004 Art. 66 and 69 of the Implementing Reg. Reimbursement between MSs Full acceptance of the request for reimbursement EESSI Liaison body State of residence Request for reimbursement of the UB provided by MS B- Art. 65/6/7 of the Reg. 883/2004 and Art. 69 of the Implementing Reg. Message 15.1 Decision to make a claim for reimbursement MS A Full acceptance of the request- information that the requested amount will be fully paid without objections Message 15.2 MS B key Flow explicitly stipulated in the Reg. Confirmation of receiving the amount reimbursed Message 15.3 Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Benefits 16 Liaison body State of the last activity Scenario 2: Art.65(6) and 65(7) of Reg. 883/2004 Art. 66 and Art. 69 of the Implementing Reg. Reimbursement between MSs Request for reimbursement is not accepted or is partially accepted EESSI Liaison body State of residence Request for reimbursement of the UB provided by MS B- Art. 65/6/7 of the Reg. 883/2004 and Art. 69 of the Implementing Reg. Decision to make a claim for reimbursement Message 16.1 MS A Information that the request is not accepted, giving a reason why (submitting it behind schedule etc.) Message 16.2 MS B key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Benefits 17 Liaison body State of the last activity Scenario 3: Art.65(6) and 65(7) of Reg. 883/2004 Art. 66 and Art. 69 of the Implementing Reg. Reimbursement between MSs Request for reimbursement is not accepted or is partially accepted; clarification of disputes and objections Liaison body EESSI State of residence MS A did not accept the request for reimbursement or partially accepted it MS A Decision to reject some expenditures-art.66(4) of the Implementing Reg. Message 17.1 Message 17.2 Further clarification of the objections Message 17.3 Message 17.4 Response etc. MS B key Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 7

158 Unemployment Benefits 18 Scenario 4: Art.65(6) and 65(7) of Reg. 883/2004 Art. 67 of the Implementing Reg. Reimbursement between MSs Possibility of charging interest Liaison body State of the last activity EESSI Liaison body State of residence MS A is too late in paying the reimbursements MS A Information about the decision whether interest will be charged or not Message 18.1 Reaction/response to the information of MS B MS B key Message 18.2 Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger Unemployment Benefits 19 Liaison body State of the last activity Scenario 2: Art.65(6) and 65(7) of Reg. 883/2004 Art. 69 of the Implementing Reg. Reimbursement between MSs Closing flows EESSI Liaison body State of residence Information about the amount reimbursed MS A realised the payment of reimbursement MS A Message 19.1 Confirmation of receiving the amount reimbursed- Notification that the reimbursement case is closed for MS B MS B key Message 19.2 Notification that the reimbursement case is closed for MS A too Message 19.3 Flow explicitly stipulated in the Reg. Flow NOT explicitly stipulated in the Reg. Trigger 8

159 Scenario 1: Change in the exclusive competence (title II of R 883/2004) Institution of former competence EESSI Institution of state subsequently competent MS A 1. Request for verification of the date of expiry of payment in MS A and notifies date when the competence has been transferred to MS B 2. Sends verified information requested and verifies the date that competency has ceased in MS A MS MSMS B Claim in MS B 3. Confirms the date of beginning of the payment 1 Explanation: This scenario covers the situation where the exclusive competence between Member States changes. It is therefore not a situation where there are two competent Member States and the priority between them in relation to family benefits would have to be settled. A claim comes to Member State B. Before the new Member State of competence starts paying its benefits it will ask Member State A for verification on when the payment of its benefits ends once it has information that the family has moved to Member State B where it will be entitled to family benefits from date X. The idea is that Member State B will not start paying before it has asked Member State A. This scenario is necessary in order to make sure that information on the new competence for family benefits is exchanged between the Member States. This is necessary in order to avoid overpayments of benefits from the Member State that the family moves from (Member State A). The rules of applicable legislation are regulated by rules in Title II in Regulation 883/2004. In case the competence between Member States changes during a calendar month the relevant rule to be applied is article 58 in the implementing regulation.

160 2 Data flow for Scenario 1: 1. Requests for verification of the date of expiry of payment in Member State A and notification of the date when the competence has been transferred to Member State B - Identification of the persons in the family concerned* - Date of moving to Member State B - Date of commencement of work in Member State B - Explanation of change in the exclusive competence Member State A should verify that activity as an employed or self-employed person has ceased in Member State A and that: (i) as a result of sickness, maternity, accident at work, occupational disease or unemployment wages and benefits have ceased; (ii) that there is no longer paid leave, strike or lock-out; and (iii) that this is not a period during which there is unpaid leave for the purposes of child-raising or a period treated as such in accordance with the legislation in Member State A. - Date of insurance and entitlement to family benefits in Member State B - Request for dates of expiry of payment - Request for possible request for reimbursement of overpayment - Amount of benefits for each child 2. Member State A sends information requested: - Date on expiry of payment - Request for reimbursement for overpayment, amount of benefits per child 3. Confirms the date of starting payment - Amount of the possible reimbursement to Member State A *In relation to the data concerning the identification of the persons the ad hoc group for family benefits refers to the data identified by the ad hoc group for identification of persons.

161 3 Scenario 2: Determination of the priority situation (articles 67, of R 883/2004 and articles 57, 58, 59.1 and 59.2 of the Impl. R) Competent institutions in other competent MS (s) New institution of competence or/and of priority 1. Inormation of the claimant and the claimants right to benefits in MS. MS C MS B 2. Request for data or verification of data about children and spouse ore other entitled person. MS A 3. Sends data asked in point 2. Claim in MS A 4. MS A decides whether it is primarily or secondarily competent and communicates with MS B.. Continues with alternative sub scenarios 2 Explanation: This scenario is the main scenario for family benefits and it covers the situations where there is a possibility of two or more competent Member States for family benefits. It is a general scenario which aims to cover the majority of cases, where there is a need to establish which Member State is primarily competent and which is secondarily competent. This scenario aims at covering articles 67, 68.1 and articles 57 and 58 of the implementing regulation, as well as article 59.1 and partly article It covers both the situation where there is a new situation with two or more Member States being competent for family benefits, as well as the situation where the order of priority between Member States changes. It also covers the situation, where the order of priority cannot be established on the basis of the children's place of residence. The trigger for the scenario is a claim for a family benefit in Member State A. The impulse for the scenario may come from an inquiry from the claimant, his/her family member or the other institution. But the actual scenario starts from a claim made in the competent Member State. The claim will often be made by the insured person him/her self but can also be made by his/her family member. The right to family benefits can be on the basis of employment, self-employment or equivalent situation treated us such (see Administrative Commission decision N 207) or, on the basis of receiving a pension or on the basis of residence. In this scenario the competent institutions tries to find out which of them is competent by priority right. As the need for information from another Member State may vary, the scenario and the data flows connected to it are flexible. The data which is needed may vary because some of the information may already be known by the Member State. This is especially the situation where the order of priority changes. The competent institution may also have received the information from the claimant and need perhaps only verification from the other Member State. The data connected to this scenario is divided into compulsory data and data

162 with can be requested in special situations. A additional menu for additional data is attached to the SED. Also from the data which is considered as compulsory can data items be deleted if the Member State concerned already has this information and don't need to request it. Data flow for Scenario 2: The following data element are considered as compulsory. However if there is already entitlements in two Member States and only a change of the priority, not all the data are requested. The clerk will have the possibility to choose which information to request Information of the claimant and the claimant s right to benefits in Member State A Identification of the claimant (X) - Identification* - Case number for competent institution A Status of claimant: - Employment or equivalent** (from to) Coded list for defining the status (see **) - Receipt of pension (from - o Insurance period, in order to determine priority based on receipt of pension (68.1.b.ii) (from to) - Residence o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) - Family member or other person who has the right to apply for family benefits o Identification* of the entitled person Family members of the claimant Spouse or other entitled person (Y) - Identification* - Status: o Employed or equivalent** (from to) Coded list for defining the status (see **) o Receipt of pension (from -) - Residence o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) - Family relationship with the claimant: o married, cohabiting, registered partnership, divorced, other

163 5 Children - Identification children concerned (name; date of birth)* - Family relationship between each child and claimant X and Y (separately) o Legal custodian of the child o Living in the same household with the child - Residence of each child: o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) Benefits and amounts of benefits - From which date the right to benefits would start according to the legislation of Member State A - Type of benefits (names of benefits in the national language) - Amounts of benefits per child, if possible *** Amount of family benefits paid for the family (if the national legislation provides for benefits for the family entity) or Amount of family benefits paid to each child *** Additional information Member State A can provide Member State B also with additional information which it marks from the "additional data menu provided data". (Additional data menu attached) 2. Request for data about children, spouse or other entitled person and benefits Spouse or other entitled person - Identification* - Status: o employed or equivalent** (from to) Coded list for defining the status (see **) o Receipt of pension (from -) - Residence o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) - Family relationship with the claimant: o Married, cohabiting, registered partnership, divorced, other - Is the parent in Member State A entitled to get family benefits

164 6 Children - Identification children concerned (name ; date of birth)* - Family relationship between each child and claimant X and Y (separately) o Legal custodian of the child o Living in the same household with the child - Residence of each child: o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) Benefits and amounts of benefits - Request for data about benefits per child or per family:*** o what kind of benefits, monthly amounts, period of payment - Period for which the information is requested (from to) - Information concerning insurance periods (requested with a horizontal business flow) Additional information Member State A can request Member State B also with additional information which it marks from the "additional data menu provided data". (Additional data menu attached) 3. Sends data asked in point 2 (the answers should be coded and the SED should include corresponding "boxes" for the answer) - Identification/Case number for competent institution B - Answer all requested information Spouse or other entitled person - Identification* - Status: o employed or equivalent** (from to) Coded list for defining the status (see **) o Receipt of pension (from -) - Residence o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) - Family relationship with the claimant: o Married, cohabiting, registered partnership, divorced, other - Is the parent in Member State A entitled to get family benefits Children - Identification children concerned (name; date of birth)*

165 7 - Family relationship between each child and claimant X and Y (separately) o Legal custodian of the child o Living in the same household with the child - Residence of each child: o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) Benefits and amounts of benefits - From which date the right to benefits would start according to the legislation of Member State A - Type of benefits (names of benefits in the national language) - Amounts of benefits per child, if possible *** Amount of family benefits paid for the family (if the national legislation provides for benefits for the family entity) or Amount of family benefits paid to each child *** - Definition of period (month/week/quarter/days) - For every child the amount of extra payments (like school fees) - The currency of each payment: (Euro) or. - The status of each payment: Temporary or Final - Information concerning insurance periods (Answered with a horizontal business flow) 4. Member State A decides whether it is primarily or secondarily competent and communicates with Member State B (and C) Communication concerning priority grounds continues according to alternative sub scenarios 2a, 2b or 2c. * In relation to the data concerning the identification of the persons the ad hoc group for family benefits refers to the data identified by the ad hoc group for identification of persons ** Or equivalent can mean a person who: - Receives cash benefits because or as a consequence of activity as an employed person or selfemployed person (meaning cash sickness or maternity benefits or parental benefits, unemployment benefits or benefits because or as a consequence accident at work or occupational disease) - Is on paid leave, strike or lock-out; - Is on unpaid leave for the purposes of child-raising or a period treated as such in accordance with the legislation in Member State A. - Is a non active person who is entitled to family benefits *** If the outcome of the proposed 59a will be that the differential amount will be paid per child separately, then all Member States are obliged to provide the information of the amount of benefits per child

166 Regarding to the outcome of the of the proposed article 59a of the IR a distinction between the two different types of family benefits should be apparent i.e. parental benefits and other family benefits 8

167 9 Sub Scenario 2 a: Primarily competent MS concludes that its legislation is applicable by priority right article 68.1 and 68.2 of R 883/2004 as well as article 59.1 and article of the Impl. R) Secondarily Competent Institution Primarily competent Institution MS B 1. Makes a decision upon benefits provided in its legislation. Informs MS B of its decision and the amount of family benefits paid. 2. In order to avoid overpayment from MS B, MS A asks for expiry date of full payment of benefits in MS B and possible request for recovery of benefits from MS B to MS A MS A 3. MS A forwards the application to MS B for the entitlement of a eventual differential supplement and informs the person concerned. Claim i in MS A 4. MS B forwards the information requested in point 2 and eventually communicates of the differential supplement. 3 Explanation: This scenario is one alternative continuation from scenario 2. It concerns a situation where the claim is made in a Member State that concludes that its legislation is applicable by priority right. In article 59.2 paragraph 3 it is stated that this Member State shall provide the benefits provided for in its legislation. In this scenario the primarily competent Member State informs the secondarily competent institution of the grounds for its decision. This is information that has been exchanged between Member States in scenario 2. Here the grounds for being primarily competent are verified. The secondarily competent institution will start the payment of the possible differential supplement as soon as possible. There can be a situation of overpayment from the other Member State in a situation where another Member State was previously competent by priority right and there is a change in the order of priority.

168 10 Data flow for Sub Scenario 2 a: 1. Makes a decision on benefits provided for in its legislation. Informs Member State B of its decision and the amount of family benefits paid. Identification - Case number in Member State A and B - Identification claimant X in Member State A * - Identification person Y* in Member State B (spouse or other entitled person) - Identification of the children concerned Informs that it considers its legislation applicable by priority right Grounds for the decision concerning priority (This is information that has already been exchanged between Member States in scenario 2. Here the grounds for being primarily competent are verified) Residence of each child: o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) Grounds for competence in Member State A and B (and C) (separately) - Employment or equivalent** (from to) Coded list for defining the status (see **) - Receipt of pension (from - o Insurance period, in order to determine priority based on receipt of pension (68.1.b.ii) (from to) - Residence o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) Data on benefits - From which date the payment starts, for each benefit - Amount of benefits per child*** - Definition of period (month/week/quarter/day) - The currency of each payments 2. In order to avoid overpayment from Member State B, Member State A asks for expiry date of full payment of benefits from Member State B and a possible request for recovery of its benefits from Member State B to Member State A. - Asks for the expiry date of (full) payment from Member State B (request an reply on a fixed date, however no later than one month from the request) - Asks for the possible amount of recovery of benefits per child***

169 3. Member State A forwards the application to Member State B for the entitlement of a differential supplement and informs the person concerned - Forwards application to Member State B (possibly in electronic or scanned form) 4. Member State B forwards the information requested in point 2. - Expiry date of (full) payment in Member State B - The requested amount of recoverable benefits per child*** 11 * In relation to the data concerning the identification of the persons the ad hoc group for family benefits refers to the data identified by the ad hoc group for identification of persons. ** Or equivalent can mean a person who: - Receives cash benefits because or as a consequence of activity as an employed person or selfemployed person (meaning cash sickness or maternity benefits or parental benefits, unemployment benefits or benefits because or as a consequence accident at work or occupational disease) - Is on paid leave, strike or lock-out; - Is on unpaid leave for the purposes of child-raising or a period treated as such in accordance with the legislation in Member State A. - Is a non active person who is entitled to family benefits ***If the outcome of the proposed 59a will be that the differential amount will be paid per child separately, then all Member States are obliged to provide the information of the amount of benefits per child Regarding to the outcome of the of the proposed article 59a of the IR a distinction between the two different types of family benefits should be apparent i.e. parental benefits and other family benefits

170 12 Sub Scenario 2 b: Secondarily competent MS concludes that its legislation is applicable but not by priority right and the other MS consequently agree on the provisional decision (article 68 of R 883/2004 and article 59.2 paragraph 3 and 59.3 of the Impl. R) Primarily competent institution Secondarily competent institution 1. MS A makes a provisional decision on priority rules stating that MS A is secondarily competent and forwards the application without delay to MS B. MS A informs the applicant. MS B 2. Provides if necessary (and when it is possible to evaluate the amount) the differential supplement to the applicant. MS A MS B has two months to take a position on the provisional decision made by MS A on the priority rules. 3. If MS B agrees or does not react, the provisional decision of MS A applies Claim in MS A 4. MS B shall pay its benefits and inform the forwarding institution the amount of benefits paid. 4 Explanation: This scenario is one alternative continuation from scenario 2. It concerns a situation where the claim is made in a Member State which concludes that its legislation is applicable but not by priority. According to article 59.3 of the implementing Regulation that Member State shall take a provisional decision on the priority right and forward the application according to article 68.3 to the other institution and inform the applicant thereof. In this scenario the secondarily competent institution informs the primarily competent institution of the grounds for its decision. This is information that has been exchanged between Member States in scenario 2. Here the grounds for being secondarily competent are verified. The secondarily competent institution shall start to pay the differential amount of its benefits as soon possible. The other Member State will have two months time to take a position on the provision decision taken. If the other institution does not react or informs that it agrees with the decision made by the first institution, it shall start paying its benefits and inform the first institution of the amount of the benefits paid.

171 13 Data flow for Sub Scenario 2 b: 1. Member State A makes a provisional decision on priority rules stating that Member State A is secondarily competent and forwards the application without delay to Member State B. Member State A Informs the applicant. Identification - Case number in Member State A and B - Identification claimant X* in Member State A - Identification person Y* in Member State B (spouse or other entitled person) - Identification of the children concerned Informs that it considers its legislation applicable but not by priority right and of the provisional decision made Grounds for the decision concerning priority (This is information that has already been exchanged between Member States in scenario 2. Here the grounds for being secondarily competent are verified) Residence of each child: o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) Grounds for competence in Member State A and B (and C) (separately) - Employment or equivalent** (from to) Coded list for defining the status (see **) - Receipt of pension (from - o Insurance period, in order to determine priority based on receipt of pension (68.1.b.ii) (from to) - Residence o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) Data on benefits - From which date the payment starts, for each benefit - Amount of benefits per child*** - Definition of period (month/week/quarter/day) - The currency of each payments 2. Provides if necessary (and when it is possible to evaluate the amount) the differential supplement to the applicant - Informs Member State B of the payment of a differential supplement

172 Member State B has two months to take a position on the provisional decision made by Member State A on the priority rules If Member State B agrees or does not react, the provisional decision of Member State A applies - Informs of agreement 4. Member State B shall pay its benefits and inform the forwarding institution of the amount of benefits paid - From which date the payment starts, for each benefit - Amount of benefits per child*** - Definition of period (month/week/quarter/day) - The currency of each payments * In relation to the data concerning the identification of the persons the ad hoc group for family benefits refers to the data identified by the ad hoc group for identification of persons. ** Or equivalent can mean a person who: - Receives cash benefits because or as a consequence of activity as an employed person or selfemployed person (meaning cash sickness or maternity benefits or parental benefits, unemployment benefits or benefits because or as a consequence accident at work or occupational disease) - Is on paid leave, strike or lock-out; - Is on unpaid leave for the purposes of child-raising or a period treated as such in accordance with the legislation in Member State A. - Is a non active person who is entitled to family benefits *** If the outcome of the proposed 59a will be that the differential amount will be paid per child separately, then all Member States are obliged to provide the information of the amount of benefits per child Regarding to the outcome of the of the proposed article 59a of the IR a distinction between the two different types of family benefits should be apparent i.e. parental benefits and other family benefits.

173 15

174 16 Sub Scenario 2 c: Disagreement between Member States about the legislation primarily applicable (article 59.3 and 59.4 of the Impl. R) MS where the children reside Institution of state subsequently competent 1. MS A makes a provisional decision on priority rules and forwards the application without delay to MS B. MS A Informs the applicant. MS B 2. MS B states within two months that it disagrees with MS A on the priority rules and informs MS A thereof MS A 3. Communication between the Member States on positions taken on the priority rules. 4. If an agreement is reached, the procedure continues accordingly. 5. If no agreement is reached the matter may be brought before the Administrative Commission, which will have six months time to reconcile the points of views Claim in MS A 6. MS B where the children reside will have to grant the benefits provided for in its legislation on a provisional basis 5 Explanation: This is one alternative continuation from scenario 2. This scenario is applied in a situation where the other Member State disagrees with the provisional decision on the priority rules in the Member State where the claim was made. It concerns a situation where the claim is made in a Member State that concludes that its legislation is applicable but not by priority. According to article 59.3 of the implementing Regulation that Member State shall take a provisional decision on the priority right and forward the application according to article 68.3 to the other institution and inform the applicant thereof. The Member State which made the provisional decision informs the other Member State and the applicant of the provisional decision. If this institution knows the amount of the benefits provided for in the legislation of the other Member State it can start to pay the differential amount of its benefits. The other Member State will have two months time to take a position on the provision decision taken. If the other institution informs that it disagrees with the provisional decision made, it shall inform the other institution of this. It will have to inform the grounds for disagreeing. The Member States in question should try to find an agreement in the situation by communicating with each other. This communication will have to be finished in one month (2 + 1). If an agreement is found, then the case continues accordingly. When no agreement is reached the disagreement is verified and acknowledgment on the disagreement will be made on both sides. The Member States will have to decide on how they will take the case to the Administrative Commission. The Member State where the children reside will have to make a provisional decision on the payment on benefits and start paying the benefits provided under its legislation.

175 17 If there is a disagreement on the residence of the children the Member State where the application is made shall start paying the full amount of benefits provided for in its legislation on a provisional basis. Data flow for Sub Scenario 2 c: 1. Member State A makes a provisional decision on priority rules and forwards the application without delay to Member State B. Member State A Informs the applicant. Identification - Case number in Member State A and B - Identification claimant X* in Member State A - Identification person Y* in Member State B (spouse or other entitled person) - Identification of the children concerned Informs that it considers its legislation applicable but not by priority right and of the provisional decision made Grounds for the decision concerning priority (This is information that has already been exchanged between Member States in scenario 2. Here the grounds for being secondarily competent are verified) Residence of each child: o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 11.1.b of the IR) Grounds for competence in Member State A and B (and C) (separately) - Employment or equivalent** (from to) Coded list for defining the status (see **) - Receipt of pension (from - o Insurance period, in order to determine priority based on receipt of pension (68.1.b.ii) (from to) - Residence o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 1.1.b of the IR) Data on benefits - From which date the payment starts, for each benefit - Amount of benefits per child*** - Definition of period (month/week/quarter/day) - The currency of each payments 2. Member State B states within two months that it disagrees with Member State A on the priority rules and informs Member State A thereof Information of grounds for disagreeing with the provisional decision made by Member State A

176 18 Residence of each child: o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 1.1.b of the IR) Grounds for competence in Member State A and B (and C) (separately) - Employment or equivalent** (from to) Coded list for defining the status (see **) - Receipt of pension (from - o Insurance period, in order to determine priority based on receipt of pension (68.1.b.ii) (from to) - Residence o Grounds for considering as resident Duration and continuity of presence in the territory of Member State A (from to) Elements of the personal situation (possibility to mark elements defined in article 1.1.b of the IR) 3. Communication between the Member States on positions taken on the priority rules. Communicating on facts concerning the residence, employment, receipt of pension of the family 4. If an agreement is reached, the procedure continues accordingly. 5. If no agreement is reached the matter may be brought before the Administrative Commission, which will have six months time to reconcile the points of views The Member States shall conclude that they have not reached to an agreement and will have to communicate on how the case will be taken before the Administrative Commission. 6. Member State B where the children reside will have to grant the benefits provided for in its legislation on a provisional basis - It shall inform the other Member State of the amounts of benefits paid per child - It there is disagreement on the residence of the children, then the Member States will have to communicate and decide on which will make the provisional basis if no other agreement is reached it will be the Member State where the claim is made * In relation to the data concerning the identification of the persons the ad hoc group for family benefits refers to the data identified by the ad hoc group for identification of persons. ** Or equivalent can mean a person who: - Receives cash benefits because or as a consequence of activity as an employed person or selfemployed person (meaning cash sickness or maternity benefits or parental benefits, unemployment benefits or benefits because or as a consequence accident at work or occupational disease) - Is on paid leave, strike or lock-out; - Is on unpaid leave for the purposes of child-raising or a period treated as such in accordance with the legislation in Member State A. - Is a non active person who is entitled to family benefits

177 *** If the outcome of the proposed 59a will be that the differential amount will be paid per child separately, then all Member States are obliged to provide the information of the amount of benefits per child Regarding to the outcome of the ad hoc group the proposed article 59a of the IR a distinction between the two different types of family benefits should be apparent i.e. parental benefits and other family benefits. 19

178 20 Sub Scenario 2 d: Where the MS that granted the benefits on a provisional basis was not the competent MS of priority (articles 59.4, 59.5 and 6.2 to 6.4 of the Impl. R) MS where the children reside MS of priority 1. MS B submits a claim for reimbursement from MS A. Makes a decision if possible on the differential amount of its benefits. MS B 2. MS A makes a decision on the payment of its benefits from the start of the contested period and makes a reimbursement to MS B. Informs MS B of the decisions taken. MS A Claim in MS A 6 Explanation: This scenario is applied in a situation where the Member State that granted the benefits on a provisional basis was not the competent Member State by priority in the end. According to article 59.4 and 59.5 and article 6.2 and 6.4 of the implementing regulation it shall claim for reimbursement from the other Member State and make, where possible, a decision of differential amount of benefits. The Member State that is considered to be competent by priority right shall make a decision of its benefits from the start of the contested period and make a reimbursement to the other Member State and inform it of the decision made. Data flow for Sub Scenario 2 d: 1. Member State B submits a claim for reimbursement from Member State A. Makes a decision if possible on the differential amount of its benefits - Amount of reimbursement per child from to (dates) - Amount of possible differential supplement per child*** 2. Member State A makes a decision on the payment of its benefits from the start of the contested period and makes a reimbursement to Member State B. Informs Member State B of the decisions taken - Amount of benefits paid under its legislation per child*** - Amount of reimbursement per child from to (dates)

179 21 *** If the outcome of the proposed 59a will be that the differential amount will be paid per child separately, then all Member States are obliged to provide the information of the amount of benefits per child Regarding to the outcome of the of the proposed article 59a of the IR a distinction between the two different types of family benefits should be apparent i.e. parental benefits and other family benefits

180 22 Scenario 3. Determination of the differential amount (Minimum annually) (article 68.2 of R 883/2004) Secondary competent institution Primarily competent institution 1. Requests for decision made on primary claim evaluation MS A MS B 2. Informs of decision made on primary claim evaluation 7 Explanation: This is a scenario for the determination of the changes in the differential amount. Institutions are requested according to article 2 in the implementing regulation to provide or exchange without delay all data necessary for establishing and determining the rights and obligations of persons to whom the Regulation applies. There is no special rule in relation to family benefits for the exchange of information when changes in the circumstances or amounts of benefits occur. Therefore the group suggests a minimum annual check for the changes in circumstances. This can affect both the priority rules and the amount of the differential amount. The secondary competent institution (Member State A) asks at least once a year the primary competent institution (Member State B) for rates of benefits payable. This request is made in order to calculate the differential amount to be paid. If Member State B has information about changes, it should inform Member State A in the reply. The scenario aims to cover art 68 (2) in 883/04. Data flow for Scenario 3: 1. Requests for decision made on primary claim evaluation - Identification of the persons concerned* (children and parents or other entitled persons) - Amounts of benefit per child and period*** - Information about any changes (for instance residence, occupation, receipt of pension) 2. Informs of decision made on primary claim evaluation - Identification of the persons concerned* (children and parents or other entitled persons) - Informs of decision made on primary claim evaluation and information about any changes. (for instance residence, occupation, receipt of pension) - Amounts of benefits per child*** and period

181 23 * In relation to the data concerning the identification of the persons the ad hoc group for family benefits refers to the data identified by the ad hoc group for identification of persons. ** *If the outcome of the proposed 59a will be that the differential amount will be paid per child separately, then all Member States are obliged to provide the information of the amount of benefits per child Regarding to the outcome of the of the proposed article 59a of the IR a distinction between the two different types of family benefits should be apparent i.e. parental benefits and other family benefits

182 24 Scenario 4 : Person with whom the children are living claims that she/he is not receiving - family benefits for maintenance of the child/children (article 68 a of R 883 (2004) ) Institution of the place of residence Competent institution by priority 1. Request to discharge benefits. MS B MS A 2. Reply to request. 8 Explanation: Person with whom the children are living in Member State B claims that she/he is not receiving family benefits for maintenance of the child/children from worker in Member State A. This scenario aims to cover article 68a in 883/04. Data flow for Scenario 4: 1. Request to discharge benefits: - Identification of the persons concerned (children and parents or other entitled persons)* - Bank account to which the money should be paid into. - Statement from the person with whom the children are living. - Legal grounds. 2. Reply to request: - Identification of the persons concerned (children and parents or other entitled persons)* - Provide reply to request as to whether they can agree to or decline the request from Member State B and, where appropriate, provide supporting information on the position taken. - Date and amount if agreed. * In relation to the data concerning the identification of the persons the ad hoc group for family benefits refers to the data identified by the ad hoc group for identification of persons.

183 25 Scenario 5: MS B is competent institution, but there are no additional or special family benefits for orphans. MS C is the MS with the longest period of insurance. MS C and MS A have special or additional family benefits for orphans following the list of CASSTM (article 69 of R 883/2004 and article 60 of the Impl. R) 1.1 Request for information about length of insurance / residence 1.2 Information about periods of insurance / residence MS A MS C 2.1 Application, relevant documents according to MS B legislation MS B 2.2 Information about priority of MS C 3.1 Possible request for additional information Claim in MS B 3.2. Reply to request Additional Commentary: Request for information about length of insurance/residence only when there are more then two MS including MS B and from the application is it not clear under which MS legislation was t he longest period of 9 insurance/residence. Explanation: This scenario covers the situation where a claim for family benefits is made in Member State B. Member State B is competent for family benefits but has no special or additional family benefits for orphans following the list of CASSTM to grant. Member State B should search from the list under which legislation the longest period of insurance or residence was completed. Therefore should ask for information by Member State concerned. In Member State B in most cases no claim for additional or special benefits for orphans (no such benefit under legislation of this Member State). But Member State B is competent for any other family benefits.

184 26 Data flow for Scenario 5: All information flows should contain: - Identification*/Case number for competent institution by priority (Member State B) - Identification of institutions (Member State B, Member State A, Member State C,...) - Identification of deceased worker (name; date of birth, all identification numbers under jurisdiction of Member State concerned if available) - Identification of children concerned (name; date of birth, identification number)* - Identification of others persons another parent or guardian applying on behalf of children (name ; date of birth, identification number, residence ) - Residence of child(ren) - Relationship between child and deceased worker - Relationship between other person and deceased worker In addition to above mentioned data: 1.1 Request for information about length of insurance/ residence. - Request for information about length of insurance/residence period of decedent person (from to) - Type of period (insurance/residence) 1.2 Information about periods of insurance/residence - Information on period (from to) - Type of period (insurance/residence) 2.1 Application, relevant documents according to Member State B legislation - Attachments any applications for family benefits, documents, - Information about family benefits provided in Member State B, amount, period. - Identification of others persons another parent or guardian applying on behalf of children (name ; date of birth, identification number, residence ) - Relationship between other person and deceased worker - Relationship between other person and child - Bank account identification 2.2 Information about priority of Member State C - Information about priority of Member State C for additional or special family benefits for orphans. 3.1 Possible request for additional information - Request for additional information. If necessary, the Member State competent for family benefits for orphans (Member State C) can request for any other information according to its legislation. 3.2 Reply to request - Reply to request * In relation to the data concerning the identification of the persons the ad hoc group for family benefits refers to the data identified by the ad hoc group for identification of persons.

185 27 Additional Data Having analysed the replies received from Member States in response to the Questionnaire from the Ad hoc Group it is evident that some Member States have requirements for specific information in order to determine entitlement to a particular family benefit in that Member State. The following is a summary of such information: Medical Reports Adoption Income The medical report should cover The child s degree of independence The degree to which assistance is required The origin of the disability the physical and mental faculties of the person examined The degree to which the person is capable or incapable of earning his/her living or attending school or training or other occupational training Prognosis In the case of adoption Date when the adopted child has been taken into the care of the adoptive parents Documents verifying the legality of the adoption Some family benefits are determined having regard to income. The requirement can relate to one or both parents and/or to the children. Type of data required: Source of income (specific benefit, from employment or self-employment; from property, valuation of land/property, alimony/maintenance payments) The period (from/to) for which the data is required. Orphans Benefits Identification of the deceased person Identification of the children concerned Identification of other persons another parent/guardian applying on behalf of the orphan/child Place of residence of the orphan/child Relationship between the orphan/child and deceased person Relationship between other person and the deceased person Occupation of the orphan/child - school - training - disability

186 28 - unemployment Income of orphan/child Other Information related to the Child Who has custody of the child? Who has parental authority of the child? Is the child adopted? Is the child maintained by public funds? Is the child attending a kindergarten is it financed by State or Community funds/ the number of hours the child attends the kindergarten? The marital status of the child Attendance school/college/training/unemployed at In some Member States family benefits can continue beyond specified age limits if the child continues to attend school/college or is registered as being unemployed. The following information may be required: Is [the child] attending: - School - College - Vocational Training Specify if such attendance is - full-time - part-time - actual attendance (e.g. 3 hours per day/5days a week)

187 Family Benefits The ad-hoc group experts on Family Benefits have identified 9 different business flows (plus one for the exchange of information). Business flow scenario 2 followed by either 2a or 2b are intended to cover the majority of situations of exchange of information between Member States. These three scenarios cover the situations where one Member State determine which Member State is primarily and which is secondarily competent to provide for family benefits and the Member States do not disagree of the result made by either of them. Each of the scenarios below is followed by relevant explanations and data. Some issues like the exchange of information in relation to insurance periods and medical certificates will be dealt with "horizontally", meaning that there will be general-purpose flows that will be used in all sectors. The ad-hoc group has also identified the exchange of data relevant in relation to residence of the children as well as residence of non active persons, when this is relevant for the acquisition of the right to family benefits. This may be a set of data which could be exchanged in a "horizontal" data flow also.

188 exchange of periods Article 6 of the Regulation 883/2004 Data flows of the insurance/ employment/ residence periods, content of data and the way periods are measured differ depending on the social security sector. I. DATA FLOWS Sickness, unemployment, family and special non-contributory benefits, benefits in case of work accidents and occupational diseases, death grants. Only insurance within a certain period of time is needed. The length of periods requested depends on the national legislation of a Member State. Trigger is almost always request of another Member State see Trigger 1 on the scheme below. In comparatively marginal amount of cases an institution of a Member State sends information on its own initiative see Trigger 2 on the scheme below. Pensions All periods over the lifetime of the person concerned are sent/ requested. Trigger can be request of the investigating institution sent to the institutions of the Member States of previous insurance/ employment of the person concerned (Trigger 1). At the same time it is always initiative of the investigating institution which sends the request to the institutions of the Member States of previous insurance/ employment and adds periods completed in the investigating Member State (Trigger 2). Scheme Trigger 1: A competent institution requests periods from another Member State Trigger 2: Any other institution receives information (e.g. by the person concerned) that the competent institution might need the periods completed under the legislation of the first institution CI Institution of another Member State Request for periods Information on periods Conclusion: Although Art of the implementing Regulation starts the procedure only by an initiative of the competent institution it is advisable to allow also the institution of any other Member State to take the initiative and send information without any request of the competent institution. II. MEASUREMENT AND CONVERSION OF PERIODS

189 Sickness, unemployment, family and special non-contributory benefits, benefits in case of work accidents and occupational diseases, death grants. The findings of Ad Hoc Groups show that periods need to be measured in calendar dates and shown as exact calendar periods from to. Pensions The findings of pensions Ad Hoc Group show that As a general rule periods can be measured in terms from to. There are periods that cannot be measured in calendar time for example bonus years granted for certain types of professions, for education of children etc. Some pension insurance periods completed during calendar periods still cannot be exactly shown in calendar time from to because they are based on the number of points, amount of contributions. Decisions to be made: 1) The present forms E205 of Member States contain tables with more detailed description of the measurement of pension periods quarters, months, weeks etc depending on the Member State. Is there detailed description of the calendar units analogical to the present E205s needed or simple from to is enough for making decision on award of pension. 2) How to show pension periods that cannot be measured in calendar time. Decision to be made by Member States and the contractor: If the periods are downloaded to the SED sent by Member StateA in the calendar units used in its legislation (for instance weeks) and sent to Member StateB which under art 13 of the Implementing Regulation will convert received periods into the units under its own legislation (let s say months), can such conversion be made inside European part of the AP. III. CONTENT OF DATA Sickness, unemployment, family and special non-contributory benefits, benefits in case of work accidents and occupational diseases, death grants. Distinction between employment, insurance and residence is enough. Pensions The types of periods are more detailed, i.e. employment, residence, compulsory insurance, voluntary insurance, equal periods (child-raising, military service, high school) etc. In addition periods can be distinguished as periods used for the entitlement and periods used for the calculation. In this content it could be useful also to examine some old documents of the Technical Commission. (ANNEX III: Insurance periods impl. giude; ANNEX IV: Characterisation of insurance period; ANNEX V: Function 1 Decision to be made: Whether more specified characteristics of the pension periods types (special scheme, profession and so on) need to be sent in SEDs. 1 These large annexes will be provided to the contractor. Of particular importance is an annexe that establishes a set of codes for each country that are to be used with a view to indicating the type of period.

190 Conclusion: The way of measurement of periods and their content slightly differ from sector to sector. However this is not serious obstacle for using common consolidated SED for the exchange of periods. In order Access Points can recognise both Member State where SED is sent and the relevant social security sector, SEDs must be identified by the Member State ID + sector ID. In such case Access Point of the receiving Member State can sort out information depending on the particular social security sector and more detailed information needed for example for the pensions award will not be sent to the family benefits institution.

191 Determination of residence (preliminary report) In the first stage, the determination of the place of residence is an internal matter. In case that after a person delivers the application, the respective institution acknowledges that this state is a state of residence; no business flow between different Member State will be necessary. However, two main situations may be found in which the exchange of data between individual Member State will be required. In order to determine the state of residence, several elements have to be determined. It is possible that an institution that determines the state of residence needs to contact the institution of other Member State with the request for information (situation 1). It is a general flow request for information, however the data i.e. required information can be fixed to a certain extent. It also does not need to be followed by the dispute between the institutions of different Member State concerning the determination of residence. Trigger in this situation would be the application for affiliation, registration or for the benefit in Member State A and a need for information from Member State B of the Member State A, which has to determine the place of residence of a person concerned. The second situation is based on the fact, that residence is not determined just for itself. It follows from the table below, the main reasons, why the state of residence of a migrant or his/her family members is fixed, is determination of the applicable legislation in general, the decision on application for affiliation or registration with certain insurance or benefit scheme or application to individual benefits. Therefore, if the institution of one Member State considers that its state is not the state of residence, generally the solution would be to transfer the application to the institution of a Member State it considers as state of residence (ether according to Art. 20 or 81 of the Implementing Regulation). This second institution can either agree with this determination, or contest it. In case of contestation, article 11 on the disputes concerning residence applies and residence should be determined by common accord (as provided by article 11). It can be done via general flow - request for information. The dispute ends when one of the disputing states accepts the existence of residence in its territory. The third situation is included in order to make reference to the applicable legislation rules on cooperation institution. Art. 20 of the implementing regulation stipulates that institution whose legislation starts to apply to a person concerned informs the previously competent state on the date it started to apply. If there is a general flow for this provision, it should be used in the case of residence as well, if not, this flow should be established. Trigger in this situation is the commencement of the applicability of the legislation of the state of residence. As regards determination of residence, data necessary for the institution to assess are of a personal nature; the source of most of them is a person concerned. The analysis of the data is based on current case law of the ECJ and also the elements listed in the Art. 11 of the Implementing Regulation is shown below.

192 Flow chart 1 of a situation, which includes the determination of residence 2 Application for insurance, registration or a benefit Institution of a Member State A If there is a need for more information from anotehr Member State - Request for information on another Member State Requested information Application for affiliation, registration or provision of a benefit Residence in Member State A Determinati on of the state of residence Dispute Residence in other Member State Institution of this Member State agrees with the conclusion of Transfer of the application to the Institution of other Member State Institution disagrees with the conslusion of Member State A Information to the institution of the other Member State previously competent state (Art. 20 of Implem. Reg) if the case concerned determination of residence in order to find the competent state. Determinati on of the state of residence 1 Flow chart is not designed to serve as bussiness flow, it is merely attempt to systematicly describe what happens between the two institutions. 2 Exchange of information between Member State that would be done through EESSI appears in blue bold.

193 Business flows Situation 1 Institution of Member State A EESSI Institution of other Member State Application for affiliation, registration or a benefit claim Member State A Request for information Provision of information Member State B Situation 2 Institution of Member State A EESSI Institution of Member State B Application for affiliation, registration or a benefit claim Member State A Decision of state of residence and transfer of application to the estimated state of Member State B Contestation of that decision Mutual exchange of information in order to reach a common accord Acceptance of the existence of residence 1 Note: 1 In case it is a Member State B who accepts, the flow will be reversed Situation 3 Institution of competent Member State A Member State A EESSI Information on the date in which the new applicable legislation started to apply to the person concerned Institution of previously competent Member Member State B

194 4 Data belonging to individual flows: Situation 1 Request for information necessary for determination of residence: Identification of a person concerned Identification of his/her family members Identification of the institution Request will relate to information on persons concerned (person and/or family members): duration of presence continuity of presence gainful activity: o identification of activity: employed/self employed o location of usual activity o if the activity/work contract is of a stable nature/long term if not gainfully active o status - student/family member/pensioner/other non gainful activities (membership in organizations and similar) family status and ties to persons in the state concerned information on type, length and place of schooling of the children housing o owned flat or house o rented flat or house limited or unlimited rental o other type of housing tax residence intention of a person concerned Additional information not listed above Reaction: Identification of a person concerned Identification of his/her family members Identification of the institution Reaction to the requests for information requested in previous step Additional information Possibility to attach scanned documents Situation 2 Decision on residence and transfer to competent state/institution: Identification of a person concerned Identification of the institution Decision on the residence Grounds for this decision (accompanied by the information on the person concerned listed in situation 1) Additional information Possibility to attach scanned documents Contestation and the exchange of information: Identification of a person concerned Identification of the institution

195 5 Information on disagreement with the previous decision Grounds (accompanied by the information on the person concerned listed in situation 1) Additional information Possibility to attach scanned documents Common accord/ acceptance of the decision: Identification of a person concerned Identification of the institution Acceptance of the residence being in the state concerned Situation 3 Identification of a person concerned Identification of his/her family members Identification of the institution Identification of the provision according to which the applicable legislation was determined Statement of the date from which legislation is applicable

196 List of articles in Regulation 883/2004, where determination of residence has the effect on the social security rights and competent Member State Article Category of person Reason for determination of residence Reason that triggers the need to contact the second Member State 11.3.e Non actives (persons who stopped working, pensioners, family members, students) Determination of applicable legislation/application for being insured or registration with a scheme of the institution of a Member State (mostly after s/he transfers the residence) 13 Persons with simultaneous activities in more Member State 17 Insured person + family member 21.1 Insured person + family member 22.1 Pension claimant + family member 23, 24, 25, 26 and 27 Pensioner + family member Determination of applicable legislation/ Application for being insured or registration with a scheme of the institution of a Member State Application for registration or benefits in kind as a person residing in other than competent state with the institution of another Member State Application for benefit in cash in case there is an agreement between the comp. institution and the institution of the place of residence about the payment of benefits Application for a pension and Application for registration or benefits in kind with the institution of a Member State Receipt of a pension and Application for registration or benefits in kind with the institution of a Member State 43.1 Pension recipient + Application for funeral grant family member 58 Insured person Examination of the entitlement to a supplement to the old-age or survivors benefits 65 Unemployed person Application for the unemployment benefits 67 Family member Application for the family benefits 68 Insured person (employed or selfemployed person) + family member Determination of the order of priority in granting family benefits a) If there is a need for information about the element determining residence from institution of other Member State b) In case institution of the first state comes to conclusion that person concerned resides in another Member State transfer of the document of registration to competent state c) In case of a dispute according Art. 11 Implem. Regulation

197 Special noncontributory benefits Application of: Trigger: Article 70 Reg.883/2004 Imp Reg Pending On his application for special non-contributory benefit, or on review of an existing award, the person advises the Competent Institution he has income or assets in another member state Competent institution (State of residence) Me mb er Sta te A EESSI Request for information about income or assets Information as requested Institution in Member State from which person receives Me mb er Sta te B Data to be supplied by Competent Institution Identification of person Identification of institution Details of period for which information is required Identification of professional or trade activity in other Member States Spouse and family details Identification of CI Data to be supplied by Institution in other state Details of income in relevant period Details of assets held in that state Further information not listed here in respect of Belgium, France, Greece and Luxembourg (to be reviewed) Comments It appears this procedure is very rarely used. A review of the process in anticipation of the assimilation of AC Decision 151 into the proposed new Implementing Reg is recommended. The Task Force should consider and make proposals to the AC. The institutions to whom the SED should be sent are listed in the Annex to AC Decision 151. Note this decision appears not to have been updated since its publication in 1994.

198 Special noncontributory benefits Application of: Trigger: Article 70 Reg.883/2004 Imp Reg Pending Person claims Special Non-Contributory Benefit in Member State A. Details of periods of employment, Self Employment or Residence in Member State B required to enable the CI to Me mb er Sta te A EESSI Request for information about periods Information about periods Me mb er Sta te B Data to be supplied by Competent Institution Identification of receiving institution Identification of person Details of period for which information is required Identification of CI Data to be supplied by Institution in other state Notification of periods of employment, self-employment or residence Identification of institution Comments It appears this procedure is very rarely used. A review of the process in anticipation of the assimilation of AC Decision 151 into the proposed new Implementing Reg is recommended. The Task Force should consider and make proposals to the AC. The institutions to whom the SED should be sent are listed in the Annex to AC Decision 151. Note this decision appears not to have been updated since its publication in 1994.

199 Art 17 Trigger: Person concerned informs the institution/designated body of a Member State of residence about the simultaneous activity in more Member State. Institution of Member State A (of residence) Institution of Member State B 1. Information on determined applicable legislation 2. Declaration of different view /non acceptance of 3. Mutual exchange of information in order to reach a common accord 4. Confirmation of applicable legislation Comment: The regulation stipulates only two exchanges of information between institutions of Member State (no. 1 and 2). It is necessary to note that the flow no. 1 will have to reach not only to one, but to all Member State where the simultaneous activity is exercised. In addition to it there is in Art. 17 (4) the procedure to be followed in case there is uncertainty about the applicable legislation. During this process it is obvious that there will be the exchange of views and information, however, it is less clear how and whether it should be put into the flow chart. Flows no. 3 and 4 were added in attempt to describe this process, that finally should lead to confirmation of one legislation applicable. Data: SED 1 Identification of the institution Identification of a person concerned Identification of his/her employer (if applicable) Decision on the applicable legislation (state code should be sufficient) Additional information (free text) Possibility to attach scanned documents SED 2 Identification of the institution Identification of a person concerned Declaration of different view Additional information (free text) Possibility to attach scanned documents SED 3 Identification of the institution Identification of a person concerned Declaration of different view/ Disagreement Additional information (free text) Possibility to attach scanned documents SED 4 Identification of a person concerned Identification of the institution Acceptance of the applicablicable legislation is of this state

200 Application of Art. 18a of the Implementing Regulation Trigger: Application of a person concerned or/and employer for the exception from general provisions on the applicable legislation in Title II delivered to the institution of Member State A (the one that should be applicable if the exception was granted). (State B is a state whose legislation would be applicable if general rules were applied.) Institution of Member State A EESSI Institution of Member State B Application for exception Member State A Application for exception Member State B Issuing a certificate of applicable leg. Refusal/Agreement Comment: There might also be a case that Member State B will require additional information - this would mean additional flow request for information and the provision of information. Do you think it should be added to the scheme? Data 1. Application for exception: Identification of the institution Identification of a person concerned Identification of his/her employer (if applicable) Identification of the category of persons (if applicable) Time period for which the exception is requested Justification Additional information Possibility to attach scanned documents Comment: Current practice differs considerably, some states do not require any information, some require strong justification and check wider range of data in order to assess the request for exception (previous insurance in state which normally should be competent, whether person is near the pensionable age, effect of the negative decision on the rights of the family members, whether the condition for posting (apart from the 12 month period) are fulfilled ties to sending employer etc.). 2. Refusal/Agreeement: Identification of the institution Identification of a person concerned

201 Identification of his/her employer (if applicable) Identification of the category of persons Decision: YES/NO If the decision is YES: Time period for which the exception is granted

202 Article 20 Additional Information 1. The relevant institutions shall as far as possible communicate to the competent institution of the Member State, whose legislation is applicable to a person by virtue of Title II of the basic Regulation, the necessary information required to establish the date on which this legislation becomes applicable and the contributions which he/she and his/her employer(s) are liable to pay under this legislation. 2. The competent institution of the Member State whose legislation becomes applicable to a person by virtue of Title II of the basic Regulation shall make the information indicating the date on which the application of this legislation takes effect available to the institution designated by the competent authority of the Member State to whose legislation that person was last subject. Article 20.1 WHY: - to establish the date on which this legislation becomes applicable and the contributions which he/she and his/her employer(s) are liable to pay WHO: - relevant institution TO WHO: - competent institution whose legislation is applicable WHAT: - the necessary information required under the legislation whose legislation is applicable. Trigger 1: institution which becomes competent needs information from previously competent institution or additional information from another institution Data SED art 20.1 (two - way) Identification of the institution Identification of the person concerned Specification on which additional information the requesting institution needs (attachment in word- or pdf- format, free text) New CI Previously CI or any other institution Request for information to be able to decide for the start of its competence Information on end of its competence and/or other requested information

203 Trigger 2: institution learns that it is not competent any more and can see that another Member State may need information Data SED art 20.1 (one - way) Identification of the institution Identification of the person concerned Information on the date on which the application of its legislation ended (There could also be other information that the former competent Member State considers as valuable for the new competent Member State. It is not possible to identify this information in advance and also in this situation the information may be provided in an attachment in wordor pdf-format). New CI Previously CI or any other institution Information on end of its competence or other requested information Article 20.2 WHY: - WHO: - competent institution whose legislation becomes applicable TO WHO: WHAT: - the institution designated by the competent authority of the Member State to whose legislation the person was last subject - make the information indicating the date on which the application of this legislation takes effect available. Trigger: The Member State to whose legislation the person was last subject needs information on the date on which the application of the legislation of the other Member State took effect. Data SED art 20.2 (two - way) Identification of the institution Identification of the person concerned Information on the date on which the application of the legislation took effect New CI Previously CI or any other institution Request for information to be able to decide for the start of its competence Information on start of its competence available

204 Recovery of benefits paid in excess and of contributions General remarks Setting up business flows (BF) for Title IV Chapter III of the Implementing Regulation (IR) is tricky because the Social Question Working Party (SQWP 1 ) has not yet agreed on this Chapter. As Section 3 of this Chapter is totally new we cannot rely on any existing procedure under Regulation (EEC) No. 574/72 but only on procedures laid down in Directive 2002/94/EC for the implementation of Directive 76/308/EEC where we do not have any social security experience. So setting up business flows has to be regarded as very preliminary. Nevertheless to put the Commission into a position to make a realistic call for tender at least the possible number of business flows has been identified. The data to be inserted into these BFs can only be finalized once the SQWP has agreed on this Chapter and additional procedural questions are fixed by the Administrative Commission (if necessary). The current work going on at the SQWP has been taken into account as far as possible. As the BF have been prepared in a very small group representing only 3 Member States we suggest that the results of our work are sent to all members of the Administrative Commission so that all Member States can add the data necessary for them, once the work at SQWP-level are finished. Especially for off-setting a detailed knowledge of the national legislation is necessary (e.g. which benefits can be taken into account for off-setting). From a systematic point of view we have tried to reduce information as far as possible to binary information Yes/No-questions or possibilities to tick alternatives out of a list. As results of our work especially the following points have to be raised before the different BF are proposed: 1) There are no specific forms under Art. 111 of Reg. 574/72 for the comparable cases under that Regulation (letting aside the request to withhold arrears in Forms E 202, E 203 and E 204). Nevertheless we propose full-fletched BF also for these provisions of the IR corresponding to this Article ) As Art. 4 (2) of the IR concerns only data exchange between institutions there were some delegations in SQWP which explained that exchange with social welfare bodies does not fall under EESSI. Therefore for the time being we do not propose a BF for Art. 71 (3) for the moment. Nevertheless it has to be acknowledged that the off-setting will be made from benefits covered by the Regulation so from the point of view of the Debtor Institution it could also be advisable not to have different procedures depending on the creditor body (either another institution or a social assistance body). This point has to be further discussed in the Task Force and possible also in the Joint Working Group. 3) During the preparation of BF for the off-setting in cases covered by Art. 6 of the IR it became evident that also Art. 6 itself would need a BF. In this context the exact field of 1 The SQWP is a Council group that studies the Implementing Regulation. AT the time of writing, it had not completed its work on the IR.

205 application of this provision has to be further examined. The Article concerns provisional competence on the one side and provisional granting of benefits on the other side. Does this necessitate 2 separate BF? This would only make sense if there might be cases where the competent Member State is clear but the granting of benefits is disputed. Letting aside family benefits where a special provision is available which also will necessitate a separate BF (Art. 59 of the IR) the provisionally competent Member State to grant benefits seems to be identical with the Member State which is provisionally considered as being competent under applicable legislation. This means that this is a question which has to lead only to one BF which should be placed under applicable legislation. Therefore we suggest that this question should be further examined in the framework of the BFs for applicable legislation. 4) We have not inserted into the list of the data required any identification details as e.g. person concerned or institution concerned as we assume that these are horizontal issues which have to be prepared by the AHGs identification and List of institutions. 5) Remarks concerning Section 3: As already said this is the most complicated part. Before going into the detailed provisions the following horizontal questions have been examined: a) In the Commissions proposal only the provisions under Dir. 76/308/EEC have been included; the additional provisions of Dir. 2002/94/EC, which, from a formalistic point of view, would also fit into the IR, have not. This is a point for discussion in the SQWP! Letting aside this formalistic point we have also taken into account the procedures laid down under Dir. 2002/94/EC knowing that these procedures apply already today in the taxation field and that most Member States will try to make the procedures of the social security field as close as possible to the procedures in the taxation field. b) Some of the procedures provided under Dir. 2002/94/EC are very specific so that a specific BF has not been proposed; these cases will easily be covered by the general BF on exchange of information (previous E 001). c) Under Dir. 2002/94/EC in 3 cases exchange on paper is the rule (requests for notification under Art.5, requests for recovery under Art. 6 and request for precautionary measures under Art. 13). It seems that - at least if courts are involved - we cannot get rid of these paper exchanges. Nevertheless between institutions we could send already electronic copies of these paper forms (e.g. in pdf format) in advance. d) As we have generally agreed that we do not need special confirmation of the receipt of a SED (the machine-confirmation is sufficient) we have also not proposed special receipt data flows in the BF for this field (c.f. Art. 5 (1) of Dir. 2002/94/EC). e) Special attention has also to be given to the identification of the requested parties. Otherwise cross border assistance in this field cannot work properly. Member States should be especially careful when drafting the lists under Annex 4 of the IR in this respect. Annexed are the 10 BFs proposed for Title IV Chapter III of the IR.

206 BF RECOV No. 1 Off-setting overpayments with arrears As it is possible that Art. 111 (1) of Reg. 574/72 is re-introduced we have preliminarily prepared a specific BF for this provision already now. Trigger: An institution finds out that it has overpaid benefits in the past and the institution of another Member State might have arrears Creditor Institution Debtor Institution SED 1) Request SED 2) Information on the arrears SED 3) Notification of payment Data necessary: SED 1: a) Information that this is a provisional request not to pay out any arrears and that further information will follow - at least information under b) has to be given (Yes/No) (in this case a second SED 1 has to be sent as soon as possible containing all missing information) b) Type of benefit which has been overpaid (tick one or more) - invalidity pension - old age pension - widows pension - widowers pension - orphans pension - other survivors pension [List has to be extended if other benefits are also included in the provision] c) Period during which overpayment has been made (insert date of start and end) d) Amount of overpayment which has to be off-set (insert amount and currency) e) Bank details (to which account the amount due should be paid) (horizontal standardised bank details) SED 2: a) Information that there are no arrears (Yes/No) b) Information that there is entitlement to corresponding benefit which could be off-set (Yes/No) c) Period during which arrears accrued (insert date of start and end) d) Amount of arrears (insert amount and currency) e) Information that arrears have already been paid out (Yes/No) f) Information that arrears cannot be off-set because the conditions are not met (Yes/No) SED 3: Date of payment on the account given under SED 1)e) (insert date)

207 BF RECOV No. 2 Off-setting of payments in excess with payments of another Member State under Art. 71 (1) of the IR Trigger: An institution finds out that it has overpaid benefits in the past and an institution of another Member State pays benefits Creditor Institution Debtor Institution SED 1) Request SED 2) Information on the deductions which are possible SED 3) Notification that the way of deduction under the legislation applied by the debtor institution is accepted SED 4) Notification of payment Data necessary: Please note: Information also concerning the conditions and limits under the legislation of both Member State concerned is not necessary as every institution has to examine this within its own responsibility. An ad hoc information for which SED 1 under BF RECOV No. 1 could be used under BF 1 seems not to be necessary under BF 2 as there is no danger that the debtor institution pays out benefits which might be lost forever. As there might be the possibility under the national legislation that overpayments of benefits of one branch are off-set with payments of benefits of another branch or with various benefits of different branches a re-iteration of the list of benefits to tick could be necessary (also this is a difference to BF RECOV No. 1). As it might be only very small amounts which are deductible under the legislation of both institutions we should open a choice for the creditor institution not to follow this path but to try to recover the amount due under Section 3 anyhow this point will also depend on the outcome of the work of the SQWP. SED 1: a) Type of benefit paid in excess by the creditor institution (tick one or more) - sickness cash benefit relating to incapacity for work - maternity/paternity benefit - long term care benefit - invalidity pension - old age pension - widows pension

208 - widowers pension - orphans pension - other survivors pension - benefit in case of accidents at work or occupational diseases - death grant - unemployment benefit - pre-retirement benefit - family benefits with the exception of parental benefits - parental benefits - special non-contributory cash benefit - other benefit - necessity for additional qualification of the benefit (it seems that this information cannot be given inside the SED as it necessitates written additional information therefore this information probably will have to be annexed to the SED) b) Period during which payment in excess has been made (insert date of start and end) c) Total amount of payment in excess which has to be off-set (limits under national legislation as to the amount have to be respected) (insert amount and currency) d) Type of benefit where the deduction can take place under national legislation applicable for the creditor institution (tick one or more) - sickness cash benefit relating to incapacity for work - maternity/paternity benefit - long term care benefit - invalidity pension - old age pension - widows pension - widowers pension - orphans pension - other survivors pension - benefit in case of accidents at work or occupational diseases - death grant - unemployment benefit - pre-retirement benefit - family benefits with the exception of parental benefits - parental benefits - special non-contributory cash benefit - other benefit - necessity for additional qualification of the benefit (it seems that this information cannot be given inside the SED as it necessitates written additional information therefore this information probably will have to be annexed to the SED) e) Can the deduction also be made from arrears of the benefit indicated under d) under the legislation applied by the creditor institution? (Yes/No) f) If the amount to be set-off can only be deducted in periodic rates (depending on the legislation applied by the creditor institution) - which periodic unity (per day/per week/per month) (tick one) - how many periodic units (insert figure) - amount to be off-set per periodic unit (insert amount and currency) g) Bank details (to which account the amount due should be paid) (horizontal standardised bank details) SED 2: a) Information that no deduction is possible taking into account the legislation applied by the creditor and the debtor institution (Yes/No)

209 b) Type of benefit where the deductions can be made under the legislation applied by the debtor institution (tick one or more) - sickness cash benefit relating to incapacity for work - maternity/paternity benefit - long term care benefit - invalidity pension - old age pension - widows pension - widowers pension - orphans pension - other survivors pension - benefit in case of accidents at work or occupational diseases - death grant - unemployment benefit - pre-retirement benefit - family benefits with the exception of parental benefits - parental benefits - special non-contributory cash benefit - other benefit - necessity for additional qualification of the benefit (it seems that this information cannot be given inside the SED as it necessitates written additional information therefore this information probably will have to be annexed to the SED) c) The deduction can also be made from arrears of the benefit indicated under b) under the legislation applied by the debtor institution (Yes/No) d) Amount of arrears which are at disposal under the legislation applied by the debtor institution (only in case under c) Yes has been ticked) (insert amount and currency) e) If the amount to be set-off can only be deducted in periodic rates or if the arrears are not sufficient to cover the amount due to the creditor institution (depending on the legislation applied by the debtor institution) - which periodic unity (per day/per week/per month) (tick one) - how many periodic units (insert figure) - amount to be off-set per periodic unit (insert amount and currency) SED 3: Notification that the way of deduction under the legislation applied by the debtor institution is accepted (Yes/No) SED 4: Date of payment on the account given under SED 1)g) (insert date)

210 BF RECOV No. 3 Off-setting of provisionally paid benefits with Payments of another Member State under Art. 71 (2): [Trigger: After a dispute over which institution is competent to grant a benefit this dispute is solved and an institution is finally competent] Trigger: An institution which has provisionally paid benefits finds out which institution is finally competent Creditor Institution Debtor Institution SED 0) Notification that the institution is competent under the applicable legislation or to pay the benefit SED 1) Request SED 2) Information on the benefits which are finally payable SED 3) Notification of payment Data necessary: Please note: Under Art. 6 of the IR first the dispute has to be settled. This is a BF which is more related to applicable legislation (see also introductory remarks). As long as no special BF has been developed in that context we want to mention such a SED as a possible starter for the BF RECOV No. 3. Up until now it is not entirely clear which amounts can be off-set. Is this only the amount of the arrears which have to be paid by the institution identified as being competent or could this provision also lead to reduction of future rates of payment by this institution? We have assumed that only the first alternative is meant. That means that any remaining rest which thus cannot be deducted has to be recovered either under Art. 71 (1) of the IR or under Section 3. In case of provisional payment of different types of benefits for each of these benefits a separate SED should be sent. Nevertheless benefits which are covered by one branch of the Regulation (like e.g. sickness cash benefits relating to incapacity for work and long term care benefits) could be dealt together if appropriate. Once again we have to stress that this provision might be influenced by the further work in the SQWP to great extent. Especially the question if there will be merged process for benefits and contributions or a separated process for both is not clear for the moment.

211 SED 0: a) Start of competence (insert date) b) Start of obligation to grant a benefit (insert date) c) Type of benefit (tick one or more) - sickness cash benefit relating to incapacity for work - maternity/paternity benefit - long term care benefit - invalidity pension - old age pension - widows pension - widowers pension - orphans pension - other survivors pension - benefit in case of accidents at work or occupational diseases - death grant - unemployment benefit - pre-retirement benefit - family benefits with the exception of parental benefits - parental benefits - special non-contributory cash benefit - other benefit - necessity for additional qualification of the benefit (it seems that this information cannot be given inside the SED as it necessitates written additional information therefore this information probably will have to be annexed to the SED) SED 1: a) Type of benefit which has been provisionally paid (tick one or more) - sickness cash benefit relating to incapacity for work - maternity/paternity benefit - long term care benefit - invalidity pension - old age pension - widows pension - widowers pension - orphans pension - other survivors pension - benefit in case of accidents at work or occupational diseases - death grant - unemployment benefit - pre-retirement benefit - family benefits with the exception of parental benefits - parental benefits - special non-contributory cash benefit - other benefit - necessity for additional qualification of the benefit (it seems that this information cannot be given inside the SED as it necessitates written additional information therefore this information probably will have to be annexed to the SED) b) Period during which payment has been made provisionally (insert date of start and end) c) Amount of provisional payments which have to be off-set (insert amount and currency) d) Bank details (to which account the amount due should be paid) (horizontal standardised bank details)

212 SED 2: a) Information that there is no entitlement to benefit which could be off-set (Yes/No) b) Information that there is entitlement to a corresponding benefit which could be off-set (Yes/No) c) Period during which this benefit is payable (insert date of start and end) d) Amount of the benefits payable for this period which can be deducted (amount and currency) SED 3: Date of payment on the account given under 1)d) (insert date)

213 BF RECOV No. 4 Off-setting of provisionally received contributions with contributions payable in another Member State under Art. 72 of the IR [Trigger: After a dispute which institution is competent under the provisions on applicable legislation this dispute is solved.] Trigger: An institution which has provisionally received contributions finds out which institution is finally competent Creditor Institution Debtor Institution SED 0) Notification that the institution is competent under the provisions on applicable legislation SED 1) Notification of amount of contributions reimbursable SED 2) Request of contributions which have to be paid SED 3) Notification of payment Data necessary: Please note: Under Art. 6 of the IR first the dispute has to be settled. This is a BF which is more related to applicable legislation. As long as no special BF has been developed in that context we want to mention such a SED as a possible starter for the BF RECOV No. 4. Nevertheless, if we agree that under Art. 6 only a SED for the start of competence is needed (as well for the of-setting of benefits as for the off-setting of contributions see also the introductory remarks), SED 0 for BF RECOV No. 3 and BF RECOV No. 4 could be identical. For the time being it is not clear if the contributions for all the different branches have to be added together and the creditor institution has the task to divide this total amount and attribute it to the different branches of social security in the Member State finally competent or if this exercise has to be done branch by branch. As long as no concrete provision is provided for this question in the implementing Regulation or by the Administrative Commission each debtor institution has to send a SED for each branch for which contributions have been paid provisionally under its legislation to the corresponding institution finally competent in the other Member State. Nevertheless benefits which are covered by one branch of the Regulation (like e.g. sickness cash benefits relating to incapacity for work and long term care benefits)

214 could be dealt together if appropriate. Once again we have to stress that this provision might be influenced by the further work in the SQWP to great extent. SED 0: a) Start of competence (insert date) b) Start of period for which contributions have to be paid (insert date) c) Type of benefit for which contributions have to be paid (tick one or more) - sickness cash benefit relating to incapacity for work - maternity/paternity benefit - long term care benefit - invalidity pension - old age pension - widows pension - widowers pension - orphans pension - other survivors pension - benefit in case of accidents at work or occupational diseases - death grant - unemployment benefit - pre-retirement benefit - family benefits with the exception of parental benefits - parental benefits - special non-contributory cash benefit - other benefit - necessity for additional qualification of the benefit (it seems that this information cannot be given inside the SED as it necessitates written additional information therefore this information probably will have to be annexed to the SED) SED 1: a) Type of benefit for which the contributions have been paid provisionally (tick one or more) - sickness cash benefit relating to incapacity for work - maternity/paternity benefit - long term care benefit - invalidity pension - old age pension - widows pension - widowers pension - orphans pension - other survivors pension - benefit in case of accidents at work or occupational diseases - death grant - unemployment benefit - pre-retirement benefit - family benefits with the exception of parental benefits - parental benefits - special non-contributory cash benefit - other benefit - necessity for additional qualification of the benefit (it seems that this information cannot be given inside the SED as it necessitates written additional information therefore this information probably will have to be annexed to the SED) [b) Period during which contributions have been paid provisionally] (only in case this information is

215 really necessary) (insert date of start and end) c) Total amount of provisionally paid contributions during that period (insert amount and currency) Please note: The base for the calculation of the contributions (income, gainful earnings etc.) should not be reported under these specific circumstances but under a general horizontal BF for applicable legislation. Also the contribution - percentage of these bases seem not relevant in that context as the finally competent Member State will apply his legislation concerning base for the calculation of contributions and contribution percentages. d) Part of these contribution which has been paid by the employer, part which has been paid by the employee if applicable (insert amount and currency) SED 2: a) Information that there are no contributions to be paid for the past (Yes/No) b) Information that contributions have to be paid for the corresponding benefits which have to be deducted from the debtor institution (Yes/No) c) Period for which these contributions have to be paid (insert date of start and end) d) Amount of contributions which have to be paid for this period (insert amount and currency) e) Part of these contribution which has been paid by the employer, part which has been paid by the employee if applicable (insert amount and currency) f) Bank details (to which account the amount due should be paid) (horizontal standardised bank details) SED 3: Date of payment on the account given under SED 2)f) (insert date)

216 BF RECOV No. 5 Request for information under Art. 73 of the IR Trigger: Institution of one Member State needs information from the other Member State in order to effectively recover its claims Applicant Party Requested Party Data necessary: SED 1) Request for information SED 2) Provision of information Please note: SED 3) Declaration of reasons for not providing information This BF concerns only requests for claims which are already clear as to their amounts. So it cannot be used to get knowledge of e.g. the income of a person to calculate the contributions (for this request of information a specific BF has to be provided (under applicable legislation). Nevertheless also in this context the income could be relevant (e.g. if under the legislation of the Applicant Party measures for recovery have to take into account the income of the debtor. SED 1 and 2 are in certain way interconnected. Under SED 1 (request for information) the Requesting Party already provides a lot of information. It is very hard to specify what other relevant data could be included under this SED. It could be infromation about a gainful activity, income, property in requested Member State or benefits payable in this state, but there might be other information that may be delivered which will depend on the special features of each individual case or of the national legislation of the Applicant Party. In this context it has to be recognized that also in the form annexed as Annex I to Dir. 2002/94/EC no further details are provided ant this form relies on added written information. It seems not to be necessary to rewrite all steps described by Dir. 2002/94/EC as separate BF (withdrawal of a request etc.). If a party makes requests and identifies that certain claims are recoverable, other states may provide information. It might be used only for recovery, if however the other state/institution does not use it afterwards (as in the meantime there was a change of circumstances) is not important. Otherwise this BF would become too complex. SED 1: a) Information of a person concerned (debtor): For natural persons: name, address, family members (name, address), his/her employer For legal entities: Name of a firm, address of a place of the seat/ headquarters, identification of responsible person

217 (the SED will be used to get the missing information) b) Information relating to the claim: - the amount owed (divided between principal amount, interests, penalties) - if the claim concerns overpaid (tick one or more) o benefits; or o contributions - date of decision permitting recovery - deadline for recovery c) Information of additional elements, like income, properties, benefits etc. in the Requested Party. (tick if the property and income status of the debtor is relevant and unknown) (Attached scanned documents) SED 2: a) All data included in SED 1 if missing; and b) if the property and income status of the debtor is requested under point c) of SED 1). Identification of gainful activity: (tick one or more, state amount if applicable) - employment o address and form of the employer o income - self-employment o business place o income - other (Attached scanned documents) Type/amount of benefit paid in requested Member State (tick one or more, state amount if applicable) - sickness cash benefit relating to incapacity for work - maternity/paternity benefit - long term care benefit - invalidity pension - old age pension - widows pension - widowers pension - orphans pension - other survivors pension - benefit in case of accidents at work or occupational diseases - death grant - unemployment benefit - pre-retirement benefit - family benefits with the exception of parental benefits - parental benefits - special non-contributory cash benefit - other benefit Identification of property owned by person/entity concerned in requested Member State (state amount if applicable) Other information (Attached scanned documents) SED 3: (tick one or more) - No information on the person available. - Information requested cannot be acquired for the purposes of similar wholly internal claims. - Information cannot be obtained in reasonable time

218

219 BF RECOV No. 6 Notification under Art. 74 of the IR Trigger: Institution of one Member State needs notify an instrument or a decision to an addressee in the other Member State in order to effectively recover its claims Applicant Party Requested Party Data necessary: Please note: SED 1) Request for notification SED 2) Information on actions taken The form of notification has been included into the data necessary as there might be a situation, in which the legislations might require the delivery directly to a person concerned, not only to the stated address or via fictional delivery (e.g. if a person concerned is notified by the post office that there is a mail but within 15 days it has not been picked up). The main content of the form in Annex II of Dir. 2002/94/EC has been reproduced in the list of data needed. Nevertheless all detailed flows of information in Dir. 2002/94/EC have not been reproduced not to overburden the BF. SED 1: a) Information about the addressee: For natural persons: name, address For legal entities: Name of a company, address of a place of the seat/ headquarters, identification of responsible person b) Information relating to the claim and notification: - type of document to be delivered o decision (tick one or more) administrative judicial o notification o other - deadline for notification - the amount owed (divided between principal amount, interests, penalties) - requested form of notification (tick one or more) o to an addressee in person o otherwise - identification whether the claim concerns (tick one or more) o overpaid benefits; or o contributions o other (Attached scanned electronic versions of the decisions that should be delivered Statement that paper original of decision will be sent by mail and must be delivered) SED 2: a) Date of notification b) Form of notification (tick one) o to an addressee in person o otherwise

220

221 BF RECOV No. 7 Request for recovery under Art. 75 of the IR or precautionary measures under Art. 80 of the IR Trigger: Institution of one Member State, in order to recover its debts needs the institution of other Member State to recover a sum for it. Applicant Party Requested Party SED 1) Request for recovery/precautionary measures SED 2) Request for paper version of a claim SED 3) Request for additional information SED 1) Giving missing details SED 4) Problems with request Data necessary: Please note: The main content of the form in Annex III of Dir. 2002/94/EC has been reproduced in the list of data needed. SED 1: a) request for (tick one or both) - recovery - precautionary measures (giving reason in attached document) b) Information on a person concerned (debtor): For natural persons: name, address, family members (name, address), his/her employer For legal entities: Name of a firm, address of a place of the seat/ headquarters, identification of responsible person c) Information relating to the claim: - the amount owed (state the amount in currency of both requested and applicant party if applicable) o principal amount o interests o penalties o costs - the branch which the claim concerns (tick one or more) o sickness benefits o maternity/paternity benefit o invalidity benefits o old age benefits o survivors benefits o benefit in case of accidents at work or occupational diseases o death grant o unemployment benefit o pre-retirement benefits o family benefits

222 o special non-contributory cash benefits - identification whether the claim concerns (tick one) o overpaid benefits o contributions o both o other - date of notification of an instrument to the addressee - date of decision permitting recovery - deadline for recovery - information concerning the third party holding assets of debtor (if applicable) e) Declaration that: (obligatory) - claim is not contested - steps taken by applicant party would not lead to payment in full of a claim. f) Bank details (to which account the amount due should be paid) (horizontal standardised bank details) g) Other information relevant for recovery (attachments, scans) (Attached scanned electronic version of an instrument permitting recovery) SED 2: Request for paper original version of the claim that should be recovered Please note: This SED is only necessary if some Member States will not require the original paper document. If all Member States will need the original then the sending will be made automatically and this SED is superfluous. SED 3: Request for information not yet given All data included in SED 1; SED 4: Information on problems on the side of the Requested Party (tick one or more) - Request cannot be recovered under the legislation applied by the Requested Party - Request cannot be recovered due to the reasons set out in Art. 79 of the IR (giving reason in attached document) - Claim cannot be recovered within a reasonable time (giving reason in attached document)

223 BF RECOV No. 8 Contestation under Art. 78 of the IR Scenario 1 Trigger: The competent body of the Member State of the applicant party receives a contestation of the claim and/or of the instrument permitting enforcement in the course of the recovery procedure in the requested party Applicant Party Requested Party SED 1) Notification of the contestation Article 78 (1) SED 2) Request to recover the contested claim Article 78 (2) second subparagraph SED 3) Information about the impossibility of recovery of contested claims according to national legislation Article 78 (2) first sentence of second subparagraph reaction on SED 2 or SED 4) Information on the continuation of the recovery procedure Article 78 (2) first sentence of second subparagraph reaction on SED 2 SED 5) Information on the decision of suspension of the enforcement procedure Article 78 (2) first subparagraph reaction on SED 1 SED 6) Information on the decision on contestation totally or partially in favour of the debtor Article 78 (2) first subparagraph SED 7) Information on the extinction or amendment of the procedure reaction on SED 6 SED 8) Information on the decision on contestation in favour of the applicant party

224 Data necessary: Please note: In principle all SEDs mentioned are necessary. It will depend on the way SEDs really will look like. If they still have some resemblance with old forms we could pack more of the proposed SEDs into one single SED with different datasets. In these cases this seems quite simple as the information usually will be of a yes/no nature like e.g. under the legislation of the requested party it is or it is not possible to recover contested claims. If we follow that approach we could merge SED 1 + 2, SED , SED 6 + 8, SED 7 would still be necessary as a SED on its own. SED 1: date of contestation SED 2: Internal provisions permitting the recovery, but the SED does not necessarily have to give the details of the national legislation; it might be a simple request SED 3: Internal provisions not permitting the recovery, but the SED does not necessarily have to give the details of the national legislation; it might be a simple request SED 4: decision and corresponding date SED 5: Internal decision and corresponding date SED 6: content of the decision and corresponding date (may be in an annex since it may result in a extinction of the procedure or a modification of the amount of the claim); new amount of the claim SED 7: content of the decision and corresponding date (may be in an annex) SED 8: decision and corresponding date Scenario 2 Trigger: The requested party receives a notification by the party concerned of a contestation of the claim and/or of the instrument permitting enforcement brought before the competent body of the Member State of the applicant party Applicant Party Requested Party SED 1) Information of the suspension of the enforcement procedure Article 78 (2) first sentence SED 2) Request to recover the contested claim Article 78 (2) second subparagraph SED 3) Information about the impossibility of recovery of contested claims according to national legislation Article 78 (2) first sentence of second subparagraph

225 or

226 SED 4) Information on the continuation of the recovery procedure Article 78 (2) first sentence of second subparagraph SED 5) Information on the decision on contestation totally or partially in favour of the debtor Article 78 (2) first subparagraph SED 6) Information on the extinction or amendment of the procedure SED 7) Information on the decision on contestation in favour of the applicant party Data necessary: Please note: This Scenario is very comparable to Scenario 1; nevertheless as the trigger is different it has to be drafted separately; many of the SEDs are the same as under Scenario 1. Also SED 3 + 4, SED could be merged. SED 1: date of notification by the party concerned; decision and corresponding date of suspension of the enforcement procedure by the requested party; copy (annex) of the contestation in order to give the possibility to the applicant party to confirm SED 2: Identical with SED 2 under Scenario 1 SED 3: Identical with SED 3 under Scenario 1 SED 4: Identical with SED 4 under Scenario 1 SED 5: Identical with SED 6 under Scenario 1 SED 6: Identical with SED 7 under Scenario 1 SED 7: Identical with SED 8 under Scenario 1

227 Scenario 3 Trigger: In the requested party a contestation concerning enforcement measures is made Applicant Party Requested Party SED 1) Information of the contestation of enforcement measures Article 78 (3) SED 2) Information on the consequences of this contestation SED 3) Additional information SED 4) Information on the result of the contestation Data necessary: Please note: This seems to be a BF where information usually has to go only one way. A reaction of the Applicant party could only be necessary when it knows about facts which could be helpful in the contestation procedure in the Member State of the Requested Party. SED 1: Information on date of the contestation SED 2: Internal provisions concerning the consequences of a contestation (national procedures, time limits (attached document) SED 3: Help by the Applicant Party to the Requested Party in the contestation procedure (attached document) SED 4: Information on the result of contestation and on whether the recovery can be continued or has to be extinct.

228 BF RECOV No. 9 Request becomes devoid or amount has to be adjusted under Art. 18 of Dir. 2002/94/EC Trigger: The party concerned pays the claim in the Member State of the applicant party or the claim is cancelled by any reason in the Member State of the applicant party or the amount of the request hast to be adjusted Applicant Party Requested Party party SED 1) Information about the facts occurred in the Member State of the applicant in result of which the request becomes devoid Article 18 (1) of Dir. 2002/94/EC SED 2) Information about the adjustment of the amount requested to recover Article 18 (2) of Dir. 2002/94/EC SED 3) Information on the extinction of the procedure Article 18 (1) of Dir. 2002/94/EC reaction to SED 1) Data necessary: SED 1: nature and date of the facts and consequences according to internal legislation SED 2: information on the changed amounts. In case of a higher amount a new BF RECOV No. 7 has to be started. Please note: In case of changes of the amount as a result of a contestation the specific SED 7) under Scenario 1 in BF RECOV No. 8 has to be used SED 3: content of the decision and corresponding date (may be in an annex)

229 BF RECOV No. 10 Final statements on results of recovery and reimbursement under Art. 81 of the IR Scenario 1 Trigger: The requested party recovers at least some of the amounts due to the Applicant Party which are more than the costs and losses incurred by the Requested Party Applicant Party Requested Party SED 1) Final statement on costs and amounts recovered and on costs and losses incurred SED 2) Notification of acceptance or non-acceptance of liability (costs and losses) SED 3) Notification of payment Data necessary: Please note: A final statement on the amounts recovered, any costs which have to be added under Art. 81 (2) or costs and losses mentioned under Art. 81 (5) of the IR and thus showing the final amount which is transferable to the Applicant Party seems to be useful. SED 1: listing of finally recovered amounts including interest, Listing of costs and/or losses, showing the amount which can finally be transferred to the Applicant Party. SED 2: Acceptance of costs and/or losses, reasoned statement in case of rejection (annexed to the SED) SED 3: Date of payment on the account given under SED 1 f) of BF RECOV No. 7

230 Scenario 2 Trigger: The requested party incurred costs and losses as a result of actions deemed to be unfounded for which the applicant party remains liable and where no amount due to the Applicant Party has been recovered or this amount is too small to cover these costs and losses Applicant Party Requested Party SED 1) Information about the amount of the costs and losses incurred SED 2) Information about acceptance or non-acceptance of liability SED 3) Notification of payment Data necessary: SED 1: a) Listing of costs and/or losses, b) Bank details (to which account the amount due should be paid) (horizontal standardised bank details) SED 2: Acceptance of costs and/or losses, reasoned statement in case of rejection (annexed to the SED) SED 3: Date of payment on the account given under SED 1

231 EUROPEAN COMMISSION DIRECTORATE-GENERAL Employment, Social Affairs and Equal Opportunities Social Protection and Integration Coordination of Social Security Schemes, Free Movement of Workers Open Call for Tender VT/2008/019 Informatics services and products in the context of the EESSI (Electronic Exchange of Social Security Information) project Technical Specifications Annex T 2 Data that compose SED messages Call for Tender VT/2008/019: Technical Specifications Annex T2

232 INTRODUCTION The following SED message composition indications aim to give the tenderers an idea of the data that the EESSI system should exchange. The data is to be exchanged within pre-determined flows and the data requirements below should be read jointly with annex T1 which describes the flows. Annexes T1 and T2 together describe the information exchange business that the contractor is to implement, as indicated in the technical specifications. The data below must be supplemented by the data which is specified in the flow annex (T1). In fact, as it happened, some ad-hoc groups have described data requirements directly in their documents on flows. This is the case, for example, of the family sector, of which you will find a succinct reference below. It is also the case of minor areas of exchange, such as that related to "Article 17", of which there is no mention below but you will find flow and data description in annex T1. Tenderers should bear in mind that, even merging the data requirements of this annex to those in annex T1, there are still small areas that still need to be covered. As specified in the Technical Part of the call-for-tender specifications, these data are neither complete nor definitive. While the flows are fairly well-known, unlikely to be further modified and few flows are still to be outlined, the data is still far from finished specifications. Member States are likely to return to it with requests for more data or for simplifying messages. There will be substantial changes to the data outlined below (and in annex T1) before, during and after the contract period. The complete data definitions are missing and, while the tenderers have an indication of how many fields are required and which fields or groups of fields - are common to several messages, what is still missing here is a characterisation of the fields. However, the Commission will provide these data in a UML 1 form, and the contractor will be able to assume that the data fields will be correctly specified. The UML data and flow representations will Specify precisely the data type Specify precisely in which messages the data items are contained Make it clearer when data items or groups of data items are common to several SED messages or sections within messages. A prime example is the Identification Data set, which is repeated almost in each message. All outstanding issues are to be discussed during workshops that are foreseen at the beginning of the contract period 2. Nevertheless, as stated above, data will also be modified throughout and after the contract period and this will be the Commission's task 3. As specified in the technical specifications (see and 3.1.1), the contractor will have to provide a tool to allow the EESSI administrators (at the Commission) to edit message types, adding, removing and modifying data items, as well as a tool to edit simple flows. This means that changes in the data composition of the messages can be implemented by the EESSI central administrators (the Commission) and, following the technical specifications, the contractor will be responsible for composing the flows and messages as specified in this annex (and in annex T1 on flows). 1 For this purpose the Commission uses "Poseidon" from 2 See the Technical Specifications, The contractor will need to apply the modifications for as long as the tool that it has to provide to the Commission is not properly delivered and accepted (see paragraph below). Call for Tender VT/2008/019: Technical Specifications Annex T2

233 Note that the data specified below concern the message body. In addition, as indicated in the technical specification, 3.1.1, the contractor will have to build the message envelope 4. The expert ad-hoc groups did not work on the envelope and tenderers will not find its description below; requirements for the envelope are in various parts of the technical specifications (see, for instance, section on "monitoring and logging"). The envelope will be the same for all messages and contain all needed information for forwarding, tracking, filing and statistics. In doing so, it must exclude all personal data. In practice, it will probably consist of a message identification number, tracking information that the contractor needs to specify, two fields for national file numbers (fixed-length, alphanumeric), a sector code, identification of the sending and receiving Competent Institutions (as indicated in the Directory) and possibly other fields, but not many. Note that different ad-hoc groups have adopted different approaches to specifying the needed data. In the Pensions, Occupational Diseases and Unemployment Benefits sector there is a strong country component, meaning that the data to be provided depends strongly on the country that receives and needs to process the claim. In the Occupational Disease sector, a large amount of data is potentially needed ("specific data", often by country), but in many cases there is a standard, more reduced set that applies ("general data"). In the sickness sector, the data requirements do not depend at all on countries, but there are different degrees of "required". These differences mirror the different business needs and practices in the different sectors. As regards two social security areas, Pensions and Sickness (AKA health insurance), the data are quite complex and probably the best way to have a gist of their complexity is by viewing them on a computer. They are in Microsoft Excel files which you will find at /.The pension data is driven by Excel macros that present the data for individual messages out of a large and complex set. You will find below the data requirements for the following sectors, corresponding to the flows in annex T1 and in the same order. Pensions Summary, complete data in (1) Sickness Summary, complete data in (1) Occupational diseases See below Unemployment See below Family Only a note, the data is in annex T1 Identification of persons See below Applicable legislation See below (1) 4 The "envelope" was called earlier "message header", for instance in the Functional Specifications Call for Tender VT/2008/019: Technical Specifications Annex T2

234 Pensions In the pensions sector there is a large amount of data that can be potentially exchanged. The enclosed PDF file lists all the variables. The separate XLS sheet at / includes a macro that allows the viewing of the specific data that compose the SEDs that are needed to initiate specific flows towards specific countries. In all cases, the specific SEDs are subsets of the whole list of data in the PDF file. In substance, the contractor will have to devise a data repository that can be queried by clerks who need to initiate flows or reply to received SEDs. The repository should return the data requirements on the basis of the clerk's (or automatic) input according to the functionalities of the XLS macro. The Excel file also provides a better way to view the pension data than the sheets below. The sheets below present all the data required, but does not tell which data is required in each flow, message or country. For this the reader should refer to the excel file.

235 Pensions data Term Institution Claimant Type of Claimant Surname Surname at Birth Forenames Previous names Sex Father s surname and forenames at birth Mother s surname and forenames at birth Family Status Family Status II Date of family status Date of Marriage Same household Description Institution to which the claim is addressed: all institutions involved (From the list of institutions) Verify whether the specified person is a widow/ widower, partner of the same sex or other (excluding children) FOR SWEDEN: If the applicant was not married to the deceased at the time of death was he/she previously married to the deceased? Minimum Data Item where a Personal Identification Number is present - AHG Identification of Persons Minimum Data Item where a Personal Identification Number is present - AHG Identification of Persons Minimum Data Item where a Personal Identification Number is present - AHG Identification of Persons Minimum Data Item where a Personal Identification Number is present - AHG Identification of Persons Indicate the civil status of a person; single, married, cohabiting, divorced, separated, remarried, widow/er, registered partnership of the same sex. Indicate as well 1st, 2nd and 3rd marriage or divorce State the date, on which the Civil status of the client was changed.e.g.: Date of marriage, cohabiting, divorce, remarried, widow/er, registered partnership of the same sex State whether the insured person lives in a same houshold as the spouse or partner and the date from which

236 Pensions data Child in Common Type of Seperation Claimant not married to the deceased at time of death Widow/widower living with another person as husband and wife Date of Remarriage Surname and Forename of other spouse Living together with another spouse Relationship Taxpayer s number Code of tax district Registration / insurance number NIP Number Lithuanian personal identification number Lithuanian state social insurance number Indicate whether the spouses have or have had a child in common (either natural or adopted children) FOR SWEDEN: Has the applicant or has the applicant had a child with the deceased? Was the woman expecting a child at the time of death? Expected date of delivery?. At the time of death were the applicant living with any children under the age of 18 of whom the applicant or the deceased were the guardian? Did the applicant and the deceased have (or had they had) a child on 31 December 1989?. On 31 December 1989 was the applicant living together with any child under the age of 16 of whom the applicant was the guardian? Name and date of birth of the youngest child. Is the applicant now living together with a child not yet 16? Name and date of birth of youngest child. Was this child at the time of death living together with the applicant? If the child is not the applicant s a copy of a judgement or other document showing who the guardian of this child is must be enclosed. Verify that the client was separated from his spouse, where applicable, and if so whether this was a de facto or de jure separation or whether they were divorced. Indicate whether claimant was previously married to the deceased or has (or has had) children by the deceased Indicate whether claimant was previously married to the cohabiting partner or has (or has had) children by the cohabiting partner State the Forename and Surname of others spouses. FOR SWEDEN: Was the surviving spouse at the time of death living together with another man with whom the surviving spouse previously was married to or with whom she has or has had a child? State the family relationship between the claimant and deceased. Example: son, daughter, adopted child, step-child grandchildren, sister, wife, husband, cohabiting partner Minimum Data Item where a Personal Identification Number is present - AHG Identification of Persons Indicate the client Lithuanian personal identification number, if available Indicate the client Lithuanian state social insurance number, if available

237 Pensions data Information about the place of residence in Switzerland Nationality Date of Birth Place of Birth Address of person Name of the beneficiary Name of the Bank Address of the Bank Identification code Account number Registration / insurance number Record number Start date of commencement of invalidity Start date of commencement of incapacity for work Invalidity caused by liable third party Invalidity result of accident at work/occ. disease Invalidity result of accident other than acc.work/occ.disease Invalidity result of injuries received on duty Invalidity result of accident in connection with duty Indicate the places where the client has been living in Switzerland : place, month, year and type of residential permission Minimum Data Item where a Personal Identification Number is present - AHG Identification of Persons State the name of the person to whom the benefit is paid or on whose behalf it is paid or if applicable, the data of the legal representavive or guardian State the title of the relevant financial institution (if IBAN is missing) State the postal location of the bank holding the account concerned.composed of : Street, Number, Postcode, Town, Country, Post distribution office, Way type, Cedex label (if IBAN is missing) State the sort code of the relevant branch of the banking institution.(bic/swift) State the international account number attributed by the banking institution (IBAN) State the file number or equivalent reference number given by the institution of the country of residence. State the date which has been determined as the commencement of invalidity State the first day on which a client is incapable for work according to the medical statement by a doctor. Indicate whether the incapacity to work is the result of an accident at work or an occupational disease. Indicate whether the incapacity to work is the result of an accident other than an accident at work or an occupational disease Indicate wheather the incapacity to work is the result of injuries received on duty or diseases occuring at the time of duty Indicate wheather the incapacity to work is the result of accident in connection with duty or disease occuring in connection with particular qualities or conditions of duty Indicate wheather invalidity is assumed caused by the claimant on purpose

238 Pensions data Invalidity caused by claimant Additional data for NL to determine invalidity Insurance against invalidity Occupational rehabilitation courses Occupation Name of employer Address of employer Start date of employment End date of employment Farm Ownership What education/courses has the claimant followed, including dates of diplomas/certificates?;does the claimant has a driving licence and if so, which category? Doe the claimant possess special experience or skills? What are the hobbies of the claimant? Indicate whether the client was/was Not insured as a worker/other than as a worker against invalidity at the moment of commencement of incapacity for work Indicate whether the client followed occupational rehabilitation courses since stopping work, specify, if medical or occupational Indicate whether the client followed occupational rehabilitation courses since stopping work, specify, if medical or occupational State the occupation for which the person has taken rehabilitation courses.ex: stone mason State the legal or business name of the employer. State the postal location of employer (registered office or place of employment).composed of : Street, Number, Postcode, Town, Country, Post distribution office, Way type, Cedex label State the first day on which the client or his/her spouse has begun to work or/and has an occupational (professional and trade) activity. The first date of commencement of employment. State the date of termination of employment. Whether the adult claimant (his/her spouse) is an owner (co-owner) or a holder of a farm; if "Yes" indicate the area of the farm (in hectares). Duty before exemption in point 7 from the additional pages after words: Foreign Intelligence Agency put following words: Military Counter-espionage Re-assess the amount of Service, Military Intelligence Service, Central Anticorruption Bureau. Policemen's pension -another pension Military pension -another pension Military service in Lithuania or former USSR Person of restricted growth Chernobyl Atomic Power Plant Indicate whether the client was on military service in Lithuania or former USSR. Indicate that the client is person of restricted growth Indicate that client is person who participated in the rectification of the consequences of the accident at the Chernobyl Atomic Power Plan or who has been evacuated from respective territories affected by radiation Indicate that the client is politicaly prosecuted Politicaly prosecuted Student before 1991 Indicate that the client was student before 1991 Studies Indicate whether the client is a full time student. If yes, a copy of certificate of educational institution should be enclosed.

239 Pensions data Time of nursing/caring at home Political prisoner Deportee Resistant Deported for forced works beyond USSR border Ghettos, concentration camps and other types of places of forced confinement during the World War II Claimant (Employment Details) Gainful employment Type of Employment I Work is dangerous Claimant employed/selfemployed Claimant partly occupied by domestic work Amont of Income Amont of Income II Frequency of Payment Hours per Week Hours per Week II Dependency of Person Compulsory pension insurance cover entailed End date of employment Indicate whether the client was nursing/caring for a disabled child under the age of 16 (for mothers) or whether the client was nursing the disabled family member of 1 group of invalidity. Indicate whether the client was political prisoner. Indicate whether the client was deportee. Indicate whether the client was resistant. Indicate whether the client was deported for forced works beyond USSR border Indicate whether the client was in ghettos, concentration camps and other types of places of forced confinement during the World War II Verify that the person concerned (child, claimant, beneficiary, spouse, cohabiting partner, common law partner, member of the family) is pursuing/engaged in, or whether the insured person on the date of death was still pursuing a gainful employment or selfemployment or an activity as a civil servant or Not Verify the clients type of employment i.e. employer, activity of selfemployed person or civil servant Indicate that client has been employed under working conditions recognised as dangerous and of arduous nature Indicate yearly income during the period immediately preceding present disability as well as weekly working hours preceding disability Indicate whether claimant during the period immediately preceding present disability has been partly occupied by domestic work, partly as employed/self-employed Monthly Amount The amount of the claimant s wage before invalidity (add. page no. 8 HU) The stated working hours for the last scope of activities before invalidity (add. page no. 8 HU) Verify that the client still pursues gainful employment entailing compulsory pension insurance cover. State the date of termination of employment either as an employee, a self-employed person or a civil servant

240 Pensions data Retirement intended Date of retirement Gainful employment intended Type of income Occupation Milirary service Period Conscript Reenlistee Other resources/sources of income Amount of income Payment frequency Claimant states No income Claimant (Benefit Details) Benefits Institution Verify that the client declares his intention to retire from gainful employment either as an employee, a self-employed person or civil servant. Start date of commencement of pension chosen by claimant. The date, when the claimant is going to retire according to his/her own announcement. IRL: Ireland uses the date that the customer actually retires. Ireland issues form RP4 to all other countries, excluding the UK, to confirm actual date of retirement. Verify that the client (claiming for old-age pension) intends to take up gainful employment as an employed/self-employed person or a civil servant Verify whether the clients income is from salary, professional fees or from other sources. Indicate that client was in military services in Latvia or the former USSR before 1996 Indicate the period im military service Mark if the client served as a conscript Mark if the client served as a reenlistee State the income (resource/type of income and sometimes the amount) received by the client. All sources of income should be considered. State the amount of income received by the client. Note: All sources of income should be considered and currency Specify the frequency of the payments. The claimant states that he/she has No income Verify whether the client has applied for or is receiving the following benefits : - continued wage or salary payments in case of illness - sickness insurance cash benefits for incapacity of work - rehabilitation allowances - - invalidity pension - old-age pension - survivor s pension - pension for accident at work or occupational disease - pension type benefit payable under compulsory motor insurance (road accident indemnity) - family benefit - unemployment benefit - early retirement benefit- benefits not covered by the Regulation - transfer of contributions (within the framework of the european institutions civil servants) - refund of contributions - other benefits. SK: State whether the client receives sickness insurance cash benefit from other Member States.HU: Only require: continued wage or salary payments in case of illness, sickness insurance cash benefits for incapacity of work, rehabilitation allowances, invalidity pension, old-age pension, pension for accident at work or occupational disease, unemployment benefit Institution responsible for payment, From the list of institutions

241 Pensions data Applied for / received May Qualify for a suvivor's Pension Social insurance pensions State pensions Invalidity (disablement) Handicap Invalidity (disablement) Claimant NO 1 Type of Pension Pension Scheme Pension Number Amount of benefits Payment frequency Start date of payment of benefits End date of payment of benefits Advances on pension claimed Indicate that the spouse/partner already receives a pension or has applied for from the scheme for employed persons, self-employed person, civil servant or all residents (must be ticked as appropriate) Indicate that the client may qualify for a survivor s pension. Indicate whether the client receives social insurance pensions (state the type of pension (old-age, work incapacity, widow(er)`s, orphan's, survivor's (paid for deceased prior to 31 December 1994), date of application, date of granting, date of suspension, institution responsible for payment of pension. In case of widow(er)`s and orphan's pensions please indicate the date of death of deceased person and whether the pension was awarded for father (mother) or for other person. Indicate whether the client receives state pensions (indicate the type of pension (old-age, work incapacity, widow(er)`s, orphan's), date of application, date of granting, date of suspension, institution responsible for payment of pension. Indicate whether the client was recognised as disabled. If yes, indicate the date of the commencement of disability and the established period of disability. Also indicate if there are or not, in annex, medical document to prove the disability Indicate whether the client was recognised with handicap. If yes, indicate if there are or not, in annex, medical document to prove the handicap Indicate whether claimant has applied for or is receiving basic benefit (covering extra expenses due to permanent illness) or assistance benefit State the type of pensions: old age pension, survivors or invalidity benefit or a combination of these. Specify the pension scheme: 1) the earnings-related pension scheme 2) the residence-based pension scheme and from which date State the pension number attributed by the institution concerned State the amount of benefit received by the client and currency Specify the frequency of the payments. State the first day from which benefits has been provided/granted and paid in the country on the contact institution State the last day the ceased benefit has been payable. Verity that the following are regarded as advances on the pension claimed: sickness insurance benefits for incapacity for work or unemployment benefits or with the nature of other. The descroption can t be finalized yet. Art. 71 ImpReg, this article is not yet discussed at the council working party meeting!

242 Pensions data Pension based on period of claimant or spouse Reduction/Rule against overlapping for benefits of same kind Reduction possible Reduction reason Request to specify part accruing from voluntary contribution Based on voluntary contributions Entitled to survivor's pension (accident) Institution Pension Number Raising a Child Institution Date of Confinement Entitlement to sickness benefits Claimant declaration: fit for work Permanently disabled Disability period Unfitness temporary/permanent Claimant declaration: constant attendance Verify whether a client who has applied for or is receiving old age or survivor s pension from the institution has his/her benefits based on: claimant s own insurance periods or insurance periods completed by the (former) spouse. Indicate that the pension award made by the contact institution may/may Not be reduced if benefits of the same kind are granted by the institution(s) concerned. Verify that the pension awarded by the contact institution may/may Not be reduced if benefits other than a benefit of the same kind are granted by another institution or if other income is received. Verify the reasons other than receipt of benefit of the same kind, why the pension granted by the contact institution may be reduced, e.g. receipt of another (specified) benefit, income from employment or self-employment or other specified income. Verify that the institution concerned should identify that part of an insured person s pension entitlement arising from his/her voluntary contribution payments. Indicate whether the benefit award is based on voluntary contributions (partly or completely) Indicate that the client has entitlement to a pension as a survivor of the deceased (death being due to an accident). Institution responsible for payment, From the list of institutions State the pension number attributed by the institution concerned Verify whether the survivor is or is Not raising a child for whom he/she is paid family allowance or an orphan s pension. HU: Indicate the number of orphans and whether they are handicapped. Institution responsible for payment, From the list of institutions State the expected date of clients confinement if she is pregnant. Indicate the clients entitlement to sickness benefits in kind. The description can t be finalized yet. Art. 30 Reg. 883/2004, the implementing rules are under discussion at the council working party meeting! Verify that the client is/is Not unfit for work (see medical report). Indicate that the client is disabled person Determine the length of period of disability if person is disabled Verify wheather a client is permanently unfit for work or temporarily unfit for a period expected to exceed three months. HU: in case of parental pension: if the claimant is under 65, please add form E 213 Verify that the client needs constant attendance, being unable to undertake without assistance Normal everyday needs such as feeding and clothing himself or that the client does Not need constant attendance (see medical report).

243 Pensions data Claimant declaration: functional capacity Claimant declaration: sufficient means of subsistence Basic Benefit Assistance Benefit (Increase Awarded) Benefits with additional benefits Educational training Benefit Benefit covering expenses for care of children Child raising periods Child raising periods II Number of children raised until 10 years old Spouse Spouse type Cohabiting partner NO 4 Surname Surname at Birth Forenames Previous name Sex Father s surname and forenames at birth Mother s surname and forenames at birth Date of Birth Indicate that the clients functional capacity has been reduced to such a degree by illness/injury that he/she is No longer able to perform ordinary everyday activities or that the illness/injury has imposed an additional long-term financial strain (see medical report) State that the client does Not have the means to support himself and his family (personal statement by the client). Verify whether the client (survivor or other (excluding children)) has applied for or is in receipt of basic benefit covering extra expenses due to permanent illness. Verify whether the client has applied for or is in receipt of benefits in respect of assistance by another person so as to enable them to perform the ordinary activities of everyday life. Verify that the client is receiving an additional benefit in respect of assistance by another person so as to enable the client to perform the ordinary activities of everyday life and that this benefit may be reduced, if a similar benefit is granted by another institution Indicate that educational/training benefit has been applied for or is in payment to a survivor. Verify whether the client (survivor or other (excluding children) has applied for or is in receipt of benefit covering expenses for care of children due to the survivors work or education. State the time the claimant /deceased spent on raising his/her child until the 16th birthday of the child Please indicate the duration the child raisinig period in the household of the claimant /deceased Bonus for three or more than three children, borns and raised at least until 10 years old Indicate that the following information concerns the specified member of the clients family,i.e. : spouse or cohabiting partner. Indicate whether the claimant previously has been married to the cohabiting partner or has (or has had) children by the cohabiting partner

244 Pensions data Place of Birth Nationality Address of person Registration / insurance number Information about the place of residence in Switzerland of the spouse or divorced spouse Information about the widow/er Date of family status Record number Military service in Lithuania or former USSR Time of nursing/caring at home Political prisoner Deportee Resistant Deported for forced works beyond USSR border Ghettos, concentration camps and other types of places of forced confinement during the World War II Survivors of the deceased who are (were) granted widow(er)`s/orphans`s pensions Surname, forename, place of residence, month, year and type of residential permission Has the widow/er been married more than one time? date of marriage, divorce or death State the date, on which the Civil status of the client was changed.e.g.: Date of marriage, cohabiting, divorce, remarried, widow/er, registered partnership of the same sex State the file number or equivalent reference number given by the institution of the country of residence. Indicate whether the deceased person was on military service in Lithuania or former USSR. Indicate whether the deceased person was nursing/caring for a disabled child under the age of 16 (for mothers) or whether the client was nursing the disabled family member of 1 group of invalidity. Indicate whether the deceased person was political prisoner Indicate whether the deceased person was deportee Indicate whether the deceased person was resistant Indicate whether the deceased person was deported for forced works beyond USSR border Indicate whether the deceased person was in ghettos, concentration camps and other types of places of forced confinement during the World War II Indicate the name and surname of the survivor, Lithuanian personal identification number, or falling this, date of birth, and institution responsible for payment of pension Spouse (Employment Details) Gainful employment Indicate that the spouse/partner pursue gainful employment

245 Pensions data Income, Benefits of allowance of the spouse Amount of income Payment frequency Fit for work Receives a Pension (Applied for/ Received) Verify whether the spouse/partner receive or not income, benefits or allowance (yes or no) NOTE: At this stage, France only need to know if the spouse has some resources. If so, they send a questionnaire to the claimant to ask for more information on the resources (nature, amount) of his/her spouse (all sources of income) State the amount of income received by the client. Note: All sources of income should be considered and currency Specify the frequency of the payments. Indicate whether the person concerned is/is Not unfit for working Indicate that the spouse/partner already receives a pension or has applied for from the scheme for employed persons, self-employed person, civil servant, all residents or occupational pensions Pension at date of Marriage Indicate whether the person was a recipient of an old age pension on the date of his/her marriage. Indicate the scheme employed perosns, self-employed persons, civil servants or all residence Pension at date of Death Pension Scheme Survivor's Insurance Type of Pension Pension number Institution Amount of benefits Payment frequency Type of Benefit Start date of payment of benefits End date of payment of benefits Spouse NO 2 Pension based on period of claimant or spouse On the day of death, was the deceased insured under legislation for survivor s benefits (whether compulsorily or voluntarily) If so, in what country and under what registration number? Verify that at the time of the clients death they were in receipt of a pension and if so whether that pension was payable out of a scheme for employed or self-employed persons civil servants or to all residents. Indicate that the deceased (employed person) was/was Not insured under legislation for survivor s insurance at date of his/her death. State the type of pensions: old age pension, survivors or invalidity benefit or a combination of these. State the pension number attributed by the institution concerned Institution responsible for payment, From the list of institutions State the amount of benefit received by the client and currency Specify the frequency of the payments. State the first day from which benefits has been provided/granted and paid in the country on the contact institution Did the deceased receive a non-duch social insurance benefit before 1 January 2000? periods, from to Indicate whether the spouse has applied for or is receiving a pension as a non-working person Verify whether a client who has applied for invalidity, old age or survivor s pension from the investigating or other institution has his/her benefits based on: the clients own insurance periods, or insurance periods completed by the (former) spouse.

246 Pensions data Deferment Deferment: Country Type of Claim Other benefits received by spouse Verify whether or Not the client has requested/the deceased had requested to postpone the payment of a pension to which he is entitled. Indicate whether the client or their spouse had requested or had obtained a refund of contributions, transfer of contributions or lumpsum payment of the deceased persons insurance Indicate whether the client or their spouse had requested or had obtained a refund of contributions, transfer of contributions or lumpsum payment of the deceased persons insurance Verify whether the spouse/partner receive or Not other benefits such as unemployment, sickness, invalidity, other Amount of benefits Payment frequency Other resources/sources of income Amount of income Payment frequency Transfer of Contributions Child raising periods Child raising periods II Spouse (Details of Death) Deceased insured on the day of death State the amount of benefit received by the client and currency Specify the frequency of the payments. State the income (resource/type of incomet) received by the client. All sources of income should be considered. State the amount of income received by the client. Note: All sources of income should be considered and currency Specify the frequency of the payments. On the day of death, was the deceased insured under legislation for survivor s benefits (whether compulsorily or voluntarily) If so, in what country and under what registration number? Place of death Date of death Cause of death accident at work Occupational Accident Only Cause of Death Activity and Place of Occupational Accident State the place the deceased person died or was officially presumed to be dead State the date the deceased person died or was officially presumed to be dead or missing person. FOR SWEDEN: Sweden needs information about missing person.state the date when the missing person was last seen alive. Indicate that the death is/is Not assumed to have been the result of an accident at work or occupational disease Registration of the occupational accident and investigation by the labour inspectorate or police and any court judgement Was the Occupational accident the only cause of death activity during which the occupational accident occurred and place of occuptional accident

247 Pensions data Type of Employment V Occuaptional Disease Death caused by 3rd party Death caused by claimant Death result of road accident Children Children Surname Forenames Registration/insurance number Sex Place of Birth Date of Birth Period of care Date of family status Date of death Relationship Raising the deceased person's children Verify that at the time of the client s death he was in receipt of a pension and if so whether that pension was payable out of a scheme for employed or self-employed persons or to all residents. if death is a result of occupational disease please provide confirmation from medical department or institution, the date of diagnosis and date of origin of disease. Please also confirm there was a link between the death and the occupational disease. Indicate that death is/is Not assumed to be the direct result of the action (or lack of action) of another person. Indicate that death is/is Not assumed to be caused by the claimant. Indicate that death is/is Not assumed to be the result of a road accident (compulsory motor liability insurance). Indicate that client has brought up 5 or more children or a child who has been recognised as invalid from childhood - up to age of eight years Indicate the period of care of the child State the date, on which the Civil status of the client was changed.e.g.: Date of marriage, cohabiting, divorce, remarried, widow/er, registered partnership of the same sex State the date, when the deseased person died or was officially presumed to be dead. State the family relationship between client and the deceased. Son, daughter, adopted child, step-child grandchildren, sister, wife, husband, cohabiting partner Indicate whether the client is raising the deceased person's children (adopted children) under the age of 18 (or if they are full time students under the age of 19) and/or nursing the deceased person's children (adopted children) - who have lost % of their capacity for work (1 Group of Invalidity), if these children became disabled under the age of 18). If yes, indicate the name and surname of children (adopted children), Lithuanian personal identification number, or falling this, date of birth and level of incapacity for work.

248 Pensions data Relationship Care of invalid or child Personal care of the child Other custody of the child Birth number of the Child Institution responsible for payment Address of Institution responsible for payment Children NO 3.1 Children NO 3.2 Children NO 3.3 Attending School Undergoing Vocational training Indicate whether the client is mother/father, guardian, stepmother/stepfather to the children he/she is rising. For Sweden: Is the survivor living together with a child not yet 21 for whom a orphan s pension is applied Indicate that the client has taken care of a group I invalid or a child who has been recognised as invalid from childhood - up to age of 16, or a person aged over 80 before 1991 Indicate the start and end date of the personal care of the child Indicate if the child is/was in custody of different person or institution and indicate where and the period (start and end) it is needed when you apply for the orphans pension Indicate whether all children are supported by the claimant. If not, state name of child(children) and its/their yearly income If the parents are married, indicate whether all children live with both parents. If not, state name of child/children in question If the parents are not married, indicate whether all the children live with both parents. If yes, state name, date of birth and income (all kinds, specify) per year of the other parent. State name of child (children) if not all children are concerned The descendants attending school - please indicate whether the educational institution in question is at secondary, intermediate or higher education level or whether the course being attended is a first degree course or a post graduate course. The descendants undergoing vocational training - please indicate whether the level of school education (secondary, intermediate or higher) required to enrol for the course in question. Unable to Work The descendants are unable to work - please indicate whether social security benefits are received because the child is unable to work and the nature of the disability. The contact institution is/is Not granting pension increase and Benefits for a child family allowance for a child or has Not yet taken decision Amount of benefits State the amount of benefit received by the client and currency State the amount of income received by the client. Note: All Amount of income sources of income should be considered and currency Payment frequency Specify the frequency of the payments. Address of child Information about children whose parents Surname, forename, place of birth, parental authority are divorced or separated

249 Pensions data Both parents dead Children under 26 year old, still at school Children Invalidity For the calculation of an orphan's benefit we have to know whether both of the parents are dead. Please also indicate whether the living parent is invalid. Children between 16 year old and under 26 year old, still at school, are entitled to survivor pensions Indicate whether the child was recognised as disabled. If yes, indicate the date of the commencement of disability and the established period of disability. Also indicate if there are or not, in annex, medical document to prove the disability under certain conditions, the amount of the old age pension can be increased (Majoration Enfant) Indicate if the claimant has raised a child, start and end of the child raising Specify the child raising period taking into account by the institution Child raising periods until his 16th birthday Art 44 Imp.Reg Child raising Art 44 (2) Imp.Reg Child raising period during the period mentioned above Art 44 (3) Imp.Reg Employment or self- Ascendants & other family members Surname Forenames Date of birth Relationship Address of person Information Concerning Child Raising Periods Specify if the claimant was subject to the legislation due to the pursuit of employment of self-emloyment activity during the period State the family relationship between client and the deceased. Son, daughter, adopted child, step-child grandchildren, sister, wife, husband, cohabiting partner Child raising Employment or selfemployment at the time the child raising period started Employment or selfemployment activity of the claimant Information Concerning Insurance Periods Period Completed Duration of Period Indicate if the claimant has raised a child, start and end of the child raising (art. 44 Imp.Reg). The child raising period is determined according to a national legislation Specify if the claimant was subject to the legislation due to the pursuit of employment of self-employment activity at the time when the child raising period started (art. 44 (2) Imp.Reg) Specify if the claimant has become subject to the legislation due to the pursuit of employment of self-emloyment activity (art. 44 (3) Imp.Reg) Year or month/year or day/month/year To be presented in days, weeks, months, quarters, years. If presented in days, please

250 Pensions data Period not based on time/not effected in time Type of Period Type of Scheme Treated as Such Occupation Information Concerning a person work history Start date of employment End date of employment Name of employer Address of employer E.g. coefficient or increase of insurance periods Voluntary or Compulsory Employment, self-employment, special scheme (e.g. civil servant/ miners), E.g. unemployment, sickness, maternity, study, military service etc. Eg Minor, Sailor State the start of the period on which the client or his/her spouse has started employment eather as an employee, a self-employed person or civil servant. State the end of the period of employment either as an employee, a self-employed person or a civil servant State the name of the employer State the postal location of employer (registered office.composed of : Street, Number, Postcode, Town, Country, Post distribution office Address additional information : Way type, Cedex label Self-employment Place of activity Place of residence during period of employment Period of residence and country Period of training and where this took place Period of a child care and where this took place Name of institution Scheme Registration/insurance number Type of insurance Date of form State the type of activity carried out as self-employed person State the place/country where the occupational activity is carried out State the place of residence during the employment. State the period of declared residence and the country State the period of training and the place where the training took place State the period of child care and the place where the child care took place State the name of the insitution where a person has been insured. State the scheme under which a person has been insured State the registration/insurance number in all institutions where a person has been insured State the type of insurance period; compulsary, voluntary, optional continued insurance or period uninsured. State the date, on which the form was subscribed by a claimant

251 Pensions data Information Concerning a decision Identification data concerning the claimant identified by ID group - Insured Person Relationship -of the Insured Person New calculation Rejection Article concerning award of benefit Start date of rule against overlapping Reduction of benefit of same kind A credited period Rule against overlapping for benefits of different kind Type of income Other resources/sources of income Article concerning limitation of rule of overlapping Number of payments per year Start date of benefits Monthly Amount Payment frequency State the date, on which the form was subscribed by a claimant State the family relationship between client and the deceased. Son, daughter, adopted child, step-child grandchildren, sister, wife, husband, cohabiting partner State if a new calculation takes place State rejection reason: Claimant/insured is still fit for work, claimant/insured person has not fulfilled the qualifying period, the limit of supplementary income is exeeded, personal circumstances of the claimant/insured person, no activity of the claimant/insured person in the country, the claimant/insured not reached the pensinable age, because of other reasons Verify the Article(s) of Reg 883/2004 under which the pension is awarded and calculated.the relevant Articles are: 52(1)(a), 52(1)(b), 52(1)(b)(i)(ii), 60(2) State the day from which the pension has been reduced pursuant to other benefits or income Indicate that the institution awarding pension has taken into account of a benefit of the same kind and state the type of benefit Indicate that the pension awarded is determied on the basis of a credited period. Indicate that the rules against the overlapping of benefits have been applied over a particular period taking into account benefits of a different kind and stating the types of benefit involved. Verify whether the clients income is from salary, professional fees Verify whether the clients income is from other sources (if so specify). Verify the Article(s) according to which the limitation has been applied against the operation of national overlapping rules. The relevant articles are: 883/2004: Art. 53(3), 55, ImpReg: Art. 10 Indicate the number of monthly payments per year. State the first day from which benefits has been awarded State the monthly amount and the currency for the application of articles: 883/2004: Art. 53(3), 55, ImpReg: Art. 10 Specify the frequency of the payments (year, quarter, month, week)

252 Pensions data Based on voluntary contributions Amount of benefits before reduction of taxes Amount of benefits after deduction of taxes Amount of basic benefits Indicate whether the benefit award is based on voluntary contribution s (partly or completely) State the monthly amount of the pension awarded (old-age, invalidity, survivors) before deduction of taxes (tax, social security contributions and any other allowable deductions), etc. Reg. 883/2004: Art. 53(3)(b), Art. 55, ImpReg: 10 Indicate whether the client is receiving an allowance or wage and if so, state either the net or gross amount of income involved.note: The gross amount of income is the total income received by the person concerned either weekly or monthly as apppropriate. The net amount is the gross amount less statutory deductions for tax and social security contributions and any other allowable deductions State the monthly amount of the pension awarded from the basic pension scheme. Note: To be filled in by a Swedish institution. Amount of supplementary pension State the monthly amount from the income related pension scheme.note: To be filled in by Swedish institutions. Type A benefits indicate, if Art. 46(2) Reg. 883/2004 is relevant Periods of less than one State if the pension claim is rejected: application of art 57 Reg year 883/2004. Suspension State if the benefit has been suspended Suppression/withdrawal State if the benefit has been suppressed/withdrawn Procedure to be followed in appeals Periods allowed for appeals Information Concerning a decision Summary State the procedure followed in appeals State the time limit for appeals Identification data concerning the claimant identified by ID group Registration/insurance number Type of Pension Institutions involved in the process State the file number or equivalent reference number given by the contact institution State the type of pensions: old age pension, survivors or invalidity benefit or a combination of these. State the institutions involved in the pension application process that have issued decision

253 Pensions data Rejection Granted pensions Number of payments per year Start date of benefits Monthly Amount Payment frequency State rejection reason: Claimant/insured is still fit for work, claimant/insured person has not fulfilled the qualifying period, the limit of supplementary income is exeeded, personal circumstances of the claimant/insured person, no activity of the claimant/insured person in the country, the claimant/insured not reached the pensinable age, because of other reasons State the institution that granted pension Indicate the number of monthly payments per year. State the first day from which benefits has been awarded State the monthly amount and the currency Specify the frequency of the payments (year, quarter, month, week) Explanations about the right to a review Information Concerning a Withdrawal Claim withdrawal Misc Date of claim Delayed notification of insurance periods Start date of payment of benefits - desired by claimant The pension scheme Start date of payment of benefits - desired by claimant III Start date of payment of benefits Payment in the state of residence Language of the decision (only in FIN) Where it appears to the claimant following receipt of the summary that his/her rights may have been adversely affected by the interaction of decisions taken by two or more institutions, the claimant has the right to a review of the decisions by the institutions concerned within the time limits provided for in the respective national legislation. The time limits shall commence on the date of receipt of the summary. State from which Member States the claimant withdraws his/her pension claim State the date of submission of the claim in the country on the contact institution or whose legislation was applicable lastly. The date on which the initial claim has been completed or a new claim submitted State the start date of entitlement to a pension desired by client. Specify the pension scheme: 1) the earnings-related pension scheme 2) the residence-based pension scheme and from which date Does the insured person wish to bring forward entitlement to the pension, if yes, one year or two years? State the first day from which benefits has been provided/granted and paid in the country on the contact institution Indicate that the client has asked for payment directly in the State of residence or to a representative in the State of origin. Indicate whether the client wishes to have the decision given to him in Finnish or in Swedish.

254 Pensions data Benefit assessment basis Tax deduction/exemption entitlement Deferment Deferment: country Provisional/advance payment benefits name, Adress of the contact investigating institution, From the list of institutions State whether the claimant is entitled to tax deduction or exemption according to italian law Verify whether or Not the client has requested/the deceased had requested to postpone the payment of a pension to which he is entitled. State the country from which the client wishes to receive a deferred pension and the date chosen for pension payments or the country from which the deceased had requested a pension to be deferred. Indicate whether the institution pays provisional benefits or makes an advance payment under Art. 50 of ImpReg.

255 Sickness Data Probably the best way of viewing the data requirements for the sickness sector is to visit the Excel sheet from which the printout below was created. Hereafter you will read notes that refer to tables A through D. These are sheet within the Excel workbook (and are also visible below the notes). The letters refer to types of flow, as follows Table A: Benefits during residence outside competent state (CS) Table B: Benefits during stays outside CS Table C: Cash benefits during residence or stay outside CS Table D: 1. Financial flows 2. Medical checks 3. Codes for refusal of claims Furthermore, the experts have denoted the required data in the tables below using the following codes. M for mandatory, i.e. must be filled otherwise SED can not be sent. MIA for mandatory if applicable. Explanation is given in a comment to the cell. Usually there are some alternatives. This field must be filled in when the situation concerns this field. NN not necessary, i.e. to be filled out if data is available and useful. NA for not applicable (in this flow). This field should not be implemented into this particular SED. R xxx: Repeated information. If a question contains some data and the reply needs the same data, R + flow name for repeat is recommended. The descriptor (M, MIA or NN) applies also to this field. Note to the contractor: Row numbering is not consistent in the tables A B C and D. Table A starts with row 1 while the other tables start wit another number. Remarks on Table A: ad row 1-6, 17 and 26: Mandatory as laid down by ID-ad hoc group ad row 7: This may be the family member with another address than the insured person. The insured person's address is not of interest if in Competent State ad row 7, flow : applicable if reason for change is change of address ad row 8: The choice of status made in this row decides if fields concerning pension claimant, pensioner or family member shall be additionally filled out ad row 9, 10, 19 and 21: Mandatory as laid down by Institution ID-ad hoc group ad flow : referral must be made to flow or Flow row 11, 12 and 15: MIA (Mandatory if applicable) in these rows because one of the rows must be filled in but not both of them: If entitlement exists: row , if entitlement does not exist: row 15. Flow row 11, 12, 14 and 15:

256 MIA as they are alternatives (When registration: row , when non-registration: row 14). Flow , row 7: Address should be mandatory in this flow as the address of the person may be unknown to the competent institution. Flow , rows 11, 12 and 14: MIA as they are alternatives (When registration: row 11+12, when non-registration: row 14). Remarks on Table B: Flow row 16, 17 and 18: MIA as they are alternatives (When entitlement: row , when no entitlement: row 18). Flow , row and 25: MIA as they are alternatives (When authorisation: row , when no entitlement: row 25). Flow and , row 32: Bank account of CI or insured person is mandatory if applicable (MIA): If the CS and State of Stay (SS) have an agreement of waiver of reimbursement the Institution of Stay will have to pay the reimbursable amount directly to the CI or the insured person. Please note: If an insured person goes to a provider and has treatment on the basis of an EHIC (or replacement form) there is no flow between institutions before the bill is sent to the competent institution via the Liaison bodies of the Competent State and the Member state of stay, cf. financial flows, table D. If a person is authorised to scheduled treatment he / she normally has a paper born certificate issued by the Competent Institution. There is thus no flow between institutions before the bill is sent to the competent institution via the Liaison bodies of the Competent State and the Member state of stay, cf. financial flows, table D. Flows between Institution of residence and Institution of the place of stay and from Competent Institution and Institution of the place of stay will thus only happen if the identity of the Institution of Stay is known. This happens if the institution has sent an SED requesting the authorisation to either the Competent Institution or the Institution of Residence. This flow is not mandatory. Remarks on Table C Flows , and , row 34 (information on in-patient treatment): The competent institution must demand from the insured person that he/she informs of any changes with possible effect on the entitlement to cash benefits such as hospitalisation. If the CI supposes that the person is in hospital it may ask the Institution on the place of stay to investigate this, cf. article 27, 5 in the implementing regulation. The descriptor is MIA as not all Member States need this information. Ad flow : Ad row 28: MIA (CI must not ask the price)

257 Flow MIA (This flow is only mandatory if in flow the price was required) The heading on the flow is amended to read REPORT of administrative checks or medical examinations or reasons for non-completion. A list ad row 26: reasons for non-completion has been included Remarks on table D, 1. Ad reference numbers, rows 22, 23 and 24: Member states have different ways of numbering invoices, inventories and credit notes. In some Member States the numbering now is done when the file is created. In others the number given by the creditor institution is changed by the liaison body before being sent in a bulk with claims from other institutions. Ad flow Down payments. Down payments relate to a percentage of the total claim. Ad Global notes: - flow B is in fact an attachment to the global note A - flow B is in fact an attachment to the global note A - flow B is in fact an attachment to the global note A - flow D is in fact an attachment to the global note C Ad flows XX.1.1 XX.1. overpayments,: The final settlement of overpayments is done by deduction in a next (later) payment Ad row 61: Attachments 1. Calculation notes: a) submission, i.e. total of claim, row 53 - down payments - credit notes - accepted contestations - overpayments final payment b) Total of months submitted, row 53 - accepted number of contested months YY months accepted x net average monthly cost amount of claim c) submission lump sum, i.e. total claim for lumpsum, row 34 - down payment - accepted contestations final payment

258 d) overpayment : - for specific persons - down payment higher than submission minus accepted contestations Ad table D, 2 claims for costs for medical reports Table D2 is to be used for reimbursement of costs for medical checks. There are no financial provisions for this flow. The expert group suggests a special SED for this financial flow as fewer data are needed than in the flows concerning benefits in kind and as claims for cost for medical checks must be sent in a file other than the one concerning benefits in kind. The SEDs concerning costs for medical checks may be sent separately or in bulks. These SEDs should be sent with the global claim note, flow A. The flows in D2 are suggested flows to Article 82, cf. TF 098/07.: Trigger: An institution needs medical or administrative examinations of a person staying or residing in another Member State Institution in Member State A Institution in place of stay or residence in Member State B Request for examination or check Information on costs exceeding a specified limit Decision if examination or check has to be made or not Results of examination or check Claim of reimbursement Acknowledgement of receipt Information on payment Contestation Information requested Contestation accepted Information on final settlement Acknowledgement Ad table D 3 Contestation codes. The list consists of codes to be used in row 54 in Table D.1.

259 CASSTM 013/08 Annex 2 Table B: Benefits during stays outside CS Dataelem Name Dataele m Descrip tion Dataelem Usage - Impl. Art. 25 cf. 883/2004 art. 19 Dataelem Usage - Impl. Art. 26 REQUEST info entitlement INFORMATION on entitlement REQUEST information on rates or amounts subject to reimbursement INFORMATION on rates or amounts subject to reimbursement, or no reimbursement REQUEST for information INFORMATION specific benefit in kind is covered by the social security REQUEST for authorisation with statement that conditions stated in Article 20(2) second sentence are / are not fulfilled REQUEST for information (E001 situation) INFORMATION (E001 situation) ((INFORMATION of) medical examination required) (RESULT of medical examination) INFORMATION of authorisation or refusal for scheduled treatment NOTIFICATION of authorisation NOTIFICATION of receipt NOTIFICATION of receipt and instruction to Institution of place of stay INFORMATION that appears medically appropriate to supplement a treatment ACKNOWLEDGEMENT AUTHORISATION or refusal ID number in competent country 6 Surname unique id of insured person within institution in competent country official name of a person 7 Surname at birth official name of a person at birth, maiden name 8 Forenames 9 Sex 10 Date of birth first name(s) associated with surname to identify a person 11 Place of birth locality where a person is born 12 Address of person address in state of residence NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN 13 Identification data of CI to be defined by ad hoc group for institution elements described by ID ad hoc group

260 CASSTM 013/08 Annex 2 Identification data of institution of the place 14 of residence to be defined by ad hoc group for institution Identification data of institution of the place 15 of stay to be defined by ad hoc group for institutions start date of 16 entitlement M MIA NA NA NA NA M NA NA NA NA M M R R M R M 17 end date of entitlement M MIA NA NA NA NA M NA NA NA NA M M R R M R M information that there 18 is no entitlement see list ad row 18 NA MIA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA 19 attachement(s) scanned invoices, medical reports etc. NA NA M R NN NN NN NN NN NN NN NN NN NN NN M NN NN information concerning reimbursements cost 20 etc. NA NA NA M NA NN NA NA NA NA NA NA NA NA NA NA NA NA specification of 21 treatment treatment which person concerned is travelling for NA NA NA NA M R M NA NA NA NA R M R R M R M information that specific treatment is covered by social 22 security NA NA NA NA NA M NA NA NA NA NA NA NA NA NA NA NA NA 23 generic data see list ad row 23 NA NA NA NA NA NA NA M M M M NN NN NN NN M R NN request for 24 authorisation when person reside in other state than competent state NA NA NA NA NA NA M NA NA NA NA NA NA NA NA M R NA authorisation or refusal for scheduled 25 treatment see list ad row 25 NA NA NA NA NA NA NA NA NA NA NA M NA NA NA NA NA M information that conditions of Article 20(2) are / are not 26 fulfilled NA NA NA NA NA NA M NA NA NA NA NA NA NA NA NA NA NA notification of 27 authorisation Art. 26(3) of Impl.Reg. NA NA NA NA NA NA NA NA NA NA NA NA M R R NA NA NA place of scheduled 28 treatment NA NA NA NA NN NN M NA NA NA NA NN M R R M R R instruction to IS that bill can be sent directly to CI via the liaison 29 bodies NA NA NA NA NA NA NA NA NA NA NA NA NA NA M NA NA NA

261 CASSTM 013/08 Annex 2 request for information concerning person's status as a frontier 30 worker see special NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA information concerning person's status as a 31 frontier worker see attache NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA bank account of the person concerned or 32 institution NA NA MIA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA List ad row 18 (reasons for refusal / cancellation of entitlement) - in message from Competent institution: List ad row 25 (reason for refusal of authorisation) a. not insured in this Member State since (date) b. not entitled to sickness benefits from this Member State a. authorisation is granted c. other reason (free text attached) b. the autorisation is not granted because treatment is not provided for d. unknown in this institution c. the autorisation is not granted because treatment can be provided in d. treatment is urgent vitally necessary List ad row 23 a. request for medical examination f. other b. medical report is attached c. request for specific information d. the treatment in row 21 is provided for in MS of residence but cannot be given within the time-limit which is medicaly justifiable e. the treatment is not provided for in MS of residence

262 CASSTM 013/08 Annex 2 Table C: Cash benefits during residence or stay outside CS Dataelem Name Dataelem Description Dataelem Usage - Impl. Art. 27 cf. 883/2004 art. 21(1) Dataelem Usage - Impl. Art. 27a cf. 883/2004 art. 21(1) Dataelem Usage - I APPLICATION for cash benefits with Certificate related to incapacity for work if necessary REQUEST for any administrative checks or medical examinations INFORMATION about costs of medical examination APPROVAL for medical examination REPORT of administrative checks or medical examinations or reasons for non-completion NOTIFICATION of payment (if necessary) or refusal of cash benefits Information of end of incapacity NOTIFICATION application for longterm care benefits (where necessary) ACKNOWLEDGEMENT REQUEST for examination of condition including all necessary information Result of examinations INFORMATION about payment of long-term cash benefits ACKNOWLEDGEMENT of receipt of the information ID number in competent country 6 Surname unique id of insured person within institution in competent country official name of a person 7 Surname at birth official name of a person at birth, maiden name 8 Forenames 9 Sex 10 Date of birth first name(s) associated with surname to identify a person 11 Place of birth locality where a person is born 12 Address of person address in state of residence M M NN R R M NN M R M R M R 13 Identification data of CI to be defined by ad hoc group for institution 14 Identification data of institution of the place of residence to be defined by ad hoc group for institution 15 Identification data of institution of the place of stay to be defined by ad hoc group for institutions 16 Status of person concerned employed; selfemployed; unemployed; non-employed; pensioner M M NN NN NN NN NN M R M R M R elements described by ID ad hoc group

263 CASSTM 013/08 Annex 2 Name and address of 17 employer MIA NA NA NA NA NA NN NA NA NN NN NN NN 18 Benefit type sickness; maternity (date of confinement); disability M NN NA NA NA M R MIA NA NN NN O NN Date incapacity 19 began M NN NA NA NA M NN MIA NA NN NN NN NN 20 Date of claim M NN NA NA NA NN NN MIA NA NN NN NN Acknowledgement of claim or of payment or 21 refusal NA NA NA NA NA NA NA NA M NN NN NN M start date of 22 entitlement NA NA NA NA NN MIA NN MIA NA NN NN M NN end date of entitlement or of 24 incapacity NA NA NA NA MIA MIA O NA NA NN NN NN NN 25 attachement(s) see list MIA M MIA NA MIA NA O NA NN M M NN NN Reasons for noncompletion 26 see list NA NA NA NA MIA NA NA NA NA NA NA NA NA Notification of refusal of 27 benefits NA NA NA NA NA MIA NA NA NA NN NA NN NN Information about costs of examination 28 required NA MIA MIA NA NA NA NA NA NA NN NA NN NN Estimated cost of medical 29 exams NA NA MIA R NA NA NA NA NA NN NA NN NN Approval for 30 examination NA NA NA MIA NA NA NA NA NA NN NN NN NN 31 information concerning longterm benefits in cash eg. weekly or monthly rate; change in payable rate & 32 date NA NA NA NA NA NA NA M NA NN NN M NN information concerning longterm benefits in kind eg. benefit type; dates & rate of 33 reimbursement NA NA NA NA NA NA NA NA NA NN NN NN NN information concerning inpatient treatment 34 MIA MIA NA NA MIA NA NA NA NA NA NA NA NA

264 CASSTM 013/08 Annex 2 List ad row 25 - attachments c. national information form list ad row 26 - reasons for non-completion of administrative checks or medical examinations b. perso a. medical certificate d. medical certificate form e. Person died c. Perso b. medical report e. other a. Person did not come for examination f. other reason d. Perso

265 CASSTM 013/08 Annex 2 Table D: 1. Financial flows Dataelem Name Datael em Descri ption Dataelem Usage - Impl. Art. 65,66,67 reimbursement procedure actual expanditure fixed amounts GLOBAL CLAIM NOTE CLAIM ACKNOWLEDGEMENT of receipt GLOBAL CREDIT NOTE CREDIT NOTE ACKNOWLEDGEMENT of receipt INFORMATION on down payments Global payment note INFORMATION on payment Global contestation note INFORMATION CONTESTATION INFORMATION requested and or acceptance of contestation INFORMATION on final settlement GLOBAL INVENTORY NOTE INVENTORY of months ACCEPTATION/REFUSAL of the inventory of months or request for further investigation REPLY: Information requested or acceptance of contestation CLAIM INFORMATION on down payments INFORMATION on final settlement CLAIM for interests INFORMATION on payment or refusal A B 65,1,3 A 65,1,2 A B B ,1,5 A B 65,1,5 C 65,1,5 D 65,1, ,1,1,A ,B ID number in competent country(debtor) unique id of insured person within institution in compete nt country NA M NA NA M NA NA NA M NA M M M NA M M M NA NA NA NA NA 7 ID number in creditor country unique id of insured person within institution in Creditor country NA NN NA NA NN NA NA NA NN NA NN NN NN NA M M M NA NA NA NA NA 8 Surname official name of a person NA M NA NA M NA NA NA M NA M M M NA M M M NA NA NA NA NA 9 Surname at birth official name of a person at birth, maiden name NA NN NA NA NN NA NA NA NN NA NN NN NN NA NN NN NN NA NA NA NA NA first name(s) associate d with surname to identify a 10 Forenames person NA M NA NA M NA NA NA M NA M M NN NA M M M NA NA NA NA NA 11 Sex NA NN NA NA NN NA NA NA NN NA NN NN NN NA NN NN NN NA NA NA NA NA 12 Date of birth NA M NA NA M NA NA NA M NA M M M NA M M M NA NA NA NA NA described by ID ad hoc group

266 CASSTM 013/08 Annex 2 elements 13 Place of birth locality where a person is born NA NN NA NA NN NA NA NA NN NA NN NN NN NA NN NN NN NA NA NA NA NA Address of 14 person 15 status of person concerned address in state of residence NA NN NA NA NN NA NA NA NN NA NN NN NN NA NN NN NN NA NA NA NA NA see list ad row 15 NA NN NA NA NN NA NA NA NN NA NN NN NN NA NN NN NN NA NA NA NA NA Identification 16 data of CI to be defined by ad hoc group for institution NA M NA NA M NA NA NA M NA M M M NA M M M NA NA NA NA NA Identification data of creditor 17 institution to be defined by ad hoc group for institution NA M NA NA M NA NA NA M NA M M M NA M M M NA NA NA NA NA Identification data of liaison body of the 18 creditor state to be defined by ad hoc group for institution s M NN M or R- 65,1,1A M NN M or R65,1,2A M M NN M NN M M M NN NN NN M M M M M to be defined by ad hoc ID data of liaison group for body in the institution 19 competent state s M NN M or R- 65,1,1A M NN M or R65,1,2A M M NN M NN M M M NN NN NN M M M M M ISO except for Great Britain Country code of which is 20 CI UK M M M or R- 65,1,1A M M M or R65,1,2A M M M M M M M M M M M M M M M M Invoice number 22 creditor NA M NA NA NA NA NA NA M NA M M M M M M M NA NA NA N A NA credit note 23 number NA NA NA NA M NA NA NA MIA NA MIA MIA MIA NA NA NA NA NA NA NA NA NA Invoice/inventory 24 number debtor NA NA NA NA NN NA NA NA NN NA NN NN NN NA NA NN NN NA NA NN NA NA Half year 25 number 1 or 2 M M M or R- 65,1,1A M M M or R65,1,2A M M M M M M M NA NA NA NA NA NA NA MIA MIA

267 CASSTM 013/08 Annex 2 26 Financial year M M M or R- 65,1,1A M M M or R65,1,2A M M M M M M M M M M M M M M M M Entitlement 27 document NA M NA NA M NA NA NA NA NA M M NA NA M M M M M M NA NA validity "from" of the entitlement 28 document NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA M M M NA NA NA NA NA validity "to" of the entitlement 29 document NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA MIA MIA MIA NA NA NA NA NA benefits 30 provided from NA M NA NA M NA NA NA NA NA M M NA NA NA M M NA NA NA NA NA benefits 31 provided to NA M NA NA M NA NA NA NA NA M M NA NA M M M NA NA NN NA NA number of 32 months NA NA NA NA NA NA NA NA NA NA NA NA NA M M M M M NA M NA NA Lump sum category (age 33 group) NA NA NA NA NA NA NA NA NA NA NA NA NA M M M M M M M NA NA 34 LUMP SUM NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA M M M NA NA amount of medical 35 treatment NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA amount of dental 36 care NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA amount of 37 medicaments NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA begin date of 38 hospitalisation NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA end date of 39 hospitalisation NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA amount of 40 hospitalisation NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA long-term care 40abenefits NA MIA NA???????????????????? NA NA NA NA NA NA NA NA NA 41 other benefits NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA amount of other 42 benefits NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA total amount of 43 benefits in kind NA MIA NA NA MIA NA NA NA NA NA MIA MIA NA NA NA NA NA NA NA NA NA NA Total 47 expenditure NA M NA NA M NA NA NA M NA M M M NA NA NA NA NA NA NA NA NA % of down 48 paiement NA NA NA NA NA NA M NA NA NA NA NA NA NA NA NA NA NA M NA NA NA Date of issue of CLAIM/CREDIT NOTE/INVENTO 49 RY NA M NA NA M NA NA NA NA NA M M M NA M M M NA NA M M M Total claim reference 50 creditor M M or R-65,1, M or R-65,1,1or R65,1,2 M M M M M M M M M M M M M M M M Total claim 51 reference debtor NA NA NA NN NN NN NN NN NN NN NN NN NN NA NA NN NN NN NN NN NN NN Total number of claims/credit NOTES/inventori 52 es M NA or R-65,1, M NA or R65,1,2 NA M NA M M M M M M M M NA NA NA NA NA 53 Total claim M M or R-65,1, M NA or R65,1,2 M M M M M M M M* M* M* M* M M M M M

268 CASSTM 013/08 Annex 2 Nature of the 54 benefits 1: sickness 2: maternity 3: Accident at work; occupatio nal disease 4: long term care MIA MIA A or R 65,1 MIA MIA A or R 65,1 MIA MIA MIA MIA MIA MIA NN NA NA NA NA NA NA NA NA NA CODE Refusal, 54 se table D3 NA NA NA NA NA NA NA NA NA M M R B NA NA NA MIA MIA NA NA NA NA MIA 55 PARTIAL NA NA NA NA MIA NA NA MIA MIA MIA MIA MIA MIA NA NA MIA MIA NA NA MIA NA NA 56 Date of event M M M M M M M M M M M M M M M M M M M M M M 57 interest rate NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA M M INTEREST 58 AMOUNT NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA M M 59 CURRENCY M NN M M NN M M M NN M NN NA M NA NA NA NA M M M M M IBAN/SWIFT code of the 60 liaison body M NA NA NA NA NA M M M NA NA NA M NA NA NA NA M M M M M 61 ATTACH/ENT SED 65,1,1 NA NA ED 65,1,2 NN NA CALCUL ATION NOTE SED 65,1,5,B NA SED 65,1,5,D MIA MIA CALCUL ATION NOTE NA NA MIA MIA CALCUL ATION NOTE CALCUL ATION NOTE CALCUL ATION NOTE CALCUL ATION NOTE MIA List ad row 15 - status of person a. worker M* total claim = number of months b. family of worker c. frontier worker d. family of frontier worker e. former frontier worker f. pensioner g. family of pensioner h. non-active person

269 CASSTM 013/08 Annex 2 Table D: 2. Medical checks 1 2 CLAIM ACKNOWLEDG EMENT of receipt INFORMATION ON PAYMENT CONTESTATION INFORMATION REQUESTED ACCEPTANCE OF CONTESTATION INFORMATION on final settlement 3 ID number in competent country(debtor country) unique id of insured person within institution in competent country M NN R R R R R elements described by ID ad hoc group 4 ID number in (creditor country) 5 Surname 6 Surname at birth unique id of insured person within institution in creditor country M NN R R R R R official name of a person M NN R R R R R official name of a person at birth, maiden name M NN R R R R R 7 Forenames first name(s) associated with surname to identify a person M NN R R R R R 8 Sex NN NN NN NN NN NN NN 9 Date of birth M NN R R R R NN 10 Place of birth locality where a person is born M NN NN NN NN NN NN Address of 11 person address in state of residence M NN NN NN NN NN NN status of person see list ad row M NN R R R R NN concerned 13 13

270 CASSTM 013/08 Annex Identification data of CI Identification data of institution of the place of residence to be defined by ad hoc group for institution M NN R R R R NN to be defined by ad hoc group for institution M NN R R R R NN ID data of liaison body in the state to be defined by of stay/residence ad hoc group for institutions M R R R R R R ID data of liaison to be defined by body in the competent state ad hoc group for institutions M R R R R R R country code of Competent Institution iso _1except for Great Britain which is UK M R R R R R R Name of document + country code M R R R R R R Invoice number 19 creditor M NN R R R R NN Invoice number 20 debtor NN MIA MIA MIA MIA NN Half year 21 number 1 or 2 M R R R R R R 22 Financial year M R R R R R R Date of request of the Medical 23 examination M NN NN R R R NN Date of the beginning of the medical 24 examination M NN NN R R R NN

271 CASSTM 013/08 Annex 2 25 Date of the end of the medical examination M NN NN R R R NN Amount of the medical 26 examinations M NN M M M M M Total 27 expenditure M R M M M M M Date of issue 28 of the E 125 M NN NN R R R NN Total claim reference of 29 creditor M R R R R R R List ad row 13 - status of person a. worker b. family of worker c. frontier worker d. family of frontier worker e. former frontier worker f. pensioner g. family of pensioner h. non-active person

272 CASSTM 013/08 Annex 2 Table D: 3. Codes for refusal of claims Liste des motifs de rejets List of reasons for rejecting claim Numéro Libellé Date ObservationText Remplissage du relevé Filling out of the invoice We are not concerned by this docume 1 Relevé ne nous concerne pas (autre pays, autre organisme de liaison liaison body) 2 Code organisme compétent absent ou erroné Institution code missing or wrong 3 Absence de l'année de référence. Year for invoice is missing Période de référence du relevé différente de la période de référence 4 de la créance Reference period of the invoice is reference period of the total claim Données d'identification (numéro, date de naisance,nom /prénom) 5 manquantes ou erronées Identification elements (number, date missing or wrong 6 Absence du code imprimé, code document d'ouverture de droit Code of entitlement document is 9 Absence de date de début ou date de fin d'ouverture des droits Begin date or end date of the form is 10 Absence du montant total des dépenses Total amount of benefits in kind Total des dépenses incorrect par rapport au détail des lignes de 11 facture The total amount is wrong compa invoice Absence du nombre de forfaits ou nombre de forfaits erroné par rapport à la 12 période de référence Number of lump-sum is missing or nu compaired to the reference period 14 Absence de la période d'hospitalisation ou période incomplète Hospitalisation period is missing 15 Absence de précisions quant aux " autres prestations " servies. Definition of "Other benefits" is m 16 Absence date de demande du contrôle médical Date of medical examination is m 17 La date réelle des soins n'a pas été indiquée The actual date of benefits is mis Droits de l'assuré Entitlement of the person Aucune affiliation n'a pu être déterminée auprès de l'organisme 18 mentionné au cadre 2 du relevé The institution in field 2 can not is insured La période de prestations n'est pas comprise dans la période 19 d'ouverture des droits The period of benefits in kind is n entitlement period 21 Les dépenses doivent être réglées forfaitairement The costs are to be settled by lu Les dépenses doivent être réglées aux couts réels à 85% (pas repris 22 en Annexe IV) The costs are to be settled by a The family member is not registe 23 Le membre de la famille n'a pas été inscrit de l'attestation de droit document 24 L'attestation de droit n'a pas été validée par vos services The entitlement document has n 25 Double facturation Numéro facdouble invoice

273 CASSTM 013/08 Annex 2 The family members don't have any e 26 Les membres de la famille n'ont pas droit à ces prestations (voir annexe III ) benefits in kind ( not listed in Annex IV 27 La fin des droits dans le pays compétent est intervenue le date Fournir les The entitlement ended at (date) Les droits de l'assuré sont ouverts au regard pays de résidence à 28 compter du date The entitlement started in the st concernés d(date) Les droits du membre de la famille sont ouverts au regard pays de 29 résidence à compter du date The family member concerned is la lettre d'i state of residence from (date) L'intéressé est titulaire d'une pension prépondérante d'un autre 30 pays The person receives a dominatin state Les soins semblent être en rapport avec l'accident du travail 31 survenu le date The benefits seems to concern a happened the (date) Les soins ne sont pas en rapport avec l'accident du travail survenu 32 le date The benefits do not concern an a happened the (date) L'intéressé(e) est titulaire d'une pension dans son pays de résidence 33 à compter du date The person receives an pension i residence from (date) 34 L'intéressé(e) est décédé(e) le date The person died the (date) 35 Cessation de résidence depuis le date Residence ceased the (date) 36 La date d'ouverture des droits dans le pays compétent se situe le date The begin date of entitlement in the (date) 39 Un décompte distinct par formulaire d'inscription est de rigueur A seperate invoice for each entitl needed Le pensionné n'est pas un ancien frontalier ( art 28,2 - XX pas repris en 43 annexe V) The pensioner is not an former forntie in annexe V) 99 autre motif Other reason (free text)

274 Occupational Diseases and Accidents at Work The structure below is by article and matches the structure of the flows in annexe T1. There are country acronyms to indicate specific data requirements by country. Article 34 (1) General data 1.1. Identification of person concerned 1.2. Identification of employer 1.3. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Date (when the accident at work occurred or when the occupational disease was first diagnosed) 2.2. For occupational diseases : Type of work (profession) Identification of the occupational disease 2.3. Period of employment 2.4. For accidents at work or commuting accidents : Type of work (profession) 2.5. Was it a commuting accident? (Yes or No) 2.6. Description of the accident where it happened how it happened what were the injuries 2.7. Other special circumstances Additional information Specific data CZ Was there alcohol, drugs, etc. involved within the accident (YES or NO - details) - Information whether general legal conditions have been contravened (YES or NO details) HU - Has the accident at work or occupational disease been caused by a liable party? If yes, the name and address. The accident was caused merely on the ground of the injured person's alcoholic status, or unconnected to the work tasks and unlicensed work/vehicle-usage, or affray at the place of employment, or by the injured person on purpose, or the injured person delayed on purpose with the recourse of medical treatment/reporting of the accident LT - an insured was not sober or was intoxicated by drugs, toxic and psychotropic substances and this was not related to the characteristics of work technologies prescribed to the employee by the employer;

275 - an insured suffered because of his/her actions, which were recognised as being of a criminal nature, or in cases when this activity was related to the violation of the administrative law; - an insured has deliberately provoked the accident; - an insured had a disease not related to his/her job; - an insured worked for himself (for his/her interests) without informing the employer; - violence was used against an insured, but circumstances of the violence and motives were not related to job, except the cases, when the accident happened on the way to/from job. UK - For accidents we need the start and finish time of the shift for the day of the accident - For commuting accidents we need the time of the accident and whether going to, returning home from or during work Article 34 (2) General data 1.1. Identification of person concerned 1.2. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Medical certificates (Scanned documents, X-rays) 2.2. Request for more information 2.3. Further information (Scanned documents, X-rays or other messages) Additional information Specific data Article 34 (4) General data 1.1. Identification of person concerned 1.2. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Medical report: 2.1. Reason of incapacity for work or case of sickness (list of reasons: an accident at work, an occupational disease, a relapse or aggravation) (Expected) duration of incapacity for work from...(date)... to...(date) In-patient treatment from...(date)... to...(date)... in a hospital or in a prevention or rehabilitation centre The accident has resulted in the following injuries (short description). 2

276 2.5. Code of initial diagnosis (by International Statistical Classification of Diseases and Related Health Problems, tenth revision) Code of conclusive diagnosis (by International Statistical Classification of Diseases and Related Health Problems, tenth revision) Treatment ended on... (date)... : (with complete recovery or not) Description of the victim s condition after recovery or at the end of medical treatment Additional information BE other pension for incapacity. Specific data GER Code of diagnosis only optional. IT Keeping into account that the disease is not generic but caused by work, it is considered necessary for the code of initial diagnosis not to use the International Statistical Classification of Diseases, but to refer to the European List of Industrial Diseases annexed to the Recommendation of the Committee of the 19th September RO type of worker (employee, self-employee, seasonal, civil servant, frontier worker). ESP - CIE 9/10 Código de identificación de enfermedad. Article 34 (5) General data 1.1. Identification of person concerned 1.2. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Request Date of accident at work or start of occupational disease Question on date after which it was no longer considered as accident at work/occupational disease Question on date from which the pension was awarded 2.2. Reply Date after which the occupational nature of the accident or disease was denied by the CI Person is entitled to receive a pension from...(date)... to...(date) Person is not entitled to a pension (indicate reasons) Additional information Specific data RO type of worker (employee, self-employee, seasonal, civil servant, frontier worker). 3

277 ES According to document 11900/07 Limite SOC (16th July 2007), this paragraph number 5 has been deleted. Article 35 (1) General data 1.1. Identification of person concerned 1.2. Identification of employer 1.3. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) (short) description of the case (if the previous documents did not include) reasons for contestation (factual and/or legal) expected date of the final decision Additional information Article 35 (2) General data Specific data BE +DATE 1.1. Identification of person concerned 1.2. Identification of employer 1.3. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Occupational accident or disease is involved? Yes or No Additional information 4

278 Article 36 (1) al 1 General data 1.1. Identification of person concerned 1.2. Identification of employer 1.3. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Date (when occupational disease was first diagnosed) Type of work (profession) Is there any causal link between the work and the occupational disease? Period of employment Circumstances under which it was diagnosed Does the person need special treatment? International Classification of the Disease Additional information Specific data PT - and also Kind of occupational disease SW - Type of work and a detailed account of the working conditions. AT - It s absolute necessary to know exposure time as exact as possible. IT - It is important to know the exposure time to the specific risky activity performed which causes the industrial disease. It is opportune to indicate the exact activity periods since the person, during his / her professional life, could perform activities which are not risky. SW - It is important to know the exposure time to the specific risky activity performed which causes the disease. IT - It is considered opportune to attach the medical / legal certificate to the diagnosis documentation IT - In this ambit it is opportune the European List of Industrial Diseases ESP - CIE 9/10 Código de identificación de enfermedad. ESP - Social Security number Article 36 (1) al 2 (A) General data: 1. Identification of person concerned 2. Identification of institutions (competent institution, institution of the State of residence or of the State of stay) 3. Identification of (all the) employers 4. Date (when occupational disease was first diagnosed) 5. Type of work (profession) 6. Is there any causal link between the work and the occupational disease? 5

279 7. Period of employment 8. Circumstances under which it was diagnosed 9. Does the person need special treatment? 10. International Classification of the Disease Additional information: Italy: It is considered opportune to underpin the necessity to modify the Art. 38 of the Basic Rules providing that the allowances are supplied in conformity with the legislation of the last of the States the conditions of which are fulfilled. This last sentence could actually create disparity in the treatment of the workers since the way it is stated it could occur that insured person is not acknowledged his / her own industrial disease in any of the States on which territory he / she has performed his /her own activity. It is well known that, the industrial diseases need specific conditions to be acknowledged; the performance of work activity; the risk exposure while performing the work activity the foreseen period of time to be affected by a disease In this ambit, which is so specific, it is necessary an ad hoc provision which does not diminish the protection of the worker. Therefore, it is opportune that, if the worker has been exposed to the risk which is susceptible to have caused the industrial disease in the last State, the latter, once it has ascertained the pathology, is the Competent State. This integration supports the motivation that the norms contained in this Article have to be expressly provided. Romania: Type of worker - (employee, self-employee, seasonal, civil servant, frontier worker) Spain: Social Security number (B) Specific data: Italy: It is important to know the exposure time to the specific risky activity performed which causes the industrial disease. It is opportune to indicate the exact activity periods since the person, during his / her professional life, could perform activities which are not risky. Portugal: Also kind of the occupational disease. Slovak Republic: We need also the data about the type of worker (employee or self-employed person). Spain: CIE 9/10 Código de identificación de enfermedad. 6

280 Sweden: Type of work and a detailed account of the working conditions. It is important to know the exposure time to the specific risky activity performed which causes the disease. Article 36 (2) (A) General data: 1. Identification of person concerned 2. Identification of institutions (competent institution, institution of the State of residence or of the State of stay) 3. Identification of (all the) employers 4. Date (when occupational disease was first diagnosed) 5. Type of work (profession) 6. Is there any causal link between the work and the occupational disease? 7. Period of employment 8. Circumstances under which it was diagnosed 9. Does the person need special treatment? 10. International Classification of the Disease 11. Final report from the institution of the last Member State, in which the insured person (victim) pursued an activity likely to cause an occupational disease and whose conditions are not satisfied (according to its legislation) 12. Information about an appeal laid down by an insured person (victim) against the Additional information: Romania: Type of worker - (employee, self-employee, seasonal, civil servant, frontier worker) Spain: Social Security number (B) Specific data: Italy: It is important to know the exposure time to the specific risky activity performed which causes the industrial disease. It is opportune to indicate the exact activity periods since the person, during his / her professional life, could perform activities which are not risky. It is considered necessary not to use the International Statistical Classification of Diseases, but to refer to the European List of Industrial Diseases annexed to the Recommendation of the Committee of the 19 th September Czech Republic: Here we need the justification why not to have the legal title. 7

281 Portugal: Also kind of the occupational disease. Slovak Republic: We need also the data about the type of worker (employee or self-employed person). Spain: CIE 9/10 Código de identificación de enfermedad. Assuming that the information is about an appeal lait down by the victim against the person that has caused the occupational desease: NO. Sweden: Type of work and a detailed account of the working conditions. It is important to know the exposure time to the specific risky activity performed which causes the disease. Article 37 (1) General data 1.1. Identification of person concerned 1.2. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Information regarding the insured event Kind of occupational disease (international classification of the disease) Date when the disease was first diagnosed Information on appeal against the decision Information on the outcome of the appeal (final decision) Additional information CZ Here we need to add the reason for worsening of the situation, documentation (medical report), we for example do not consider the age more less we need all as it is above in table number 7. Specific data A - Codes of initial diagnosis or of conclusive diagnosis or international classifications of the disease have not played a role until now in the practical work of the accident insurance (in connexion with reg (EC) no 1408/71) DE - Germany doesn`t use the international classification of the disease I Italy use the European list of industrial disease Article 37 (2) General data 1.1. Identification of person concerned 8

282 1.2. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Information regarding the insured event Kind of occupational disease (international classification of the disease) Date when the disease was first diagnosed 2.2. Provisional payment Request for amount of provisional payment to be paid (monthly amount in EUR or other currency of an EU-country) Reply : Amount of provisional payment to be paid Date of payment and actual amount paid 2.3. Final reimbursement Request for amount of final payment paid Reply : Total sum and monthly amount in EUR or other currency of an EU-country and banking references Date of reimbursement and final amount paid 3.6.Additional information Specific data DE - Germany doesn`t use the international classification of the disease I Italy use the European list of industrial disease Article 38 General data 1.1. Identification of person concerned 1.2. Identification of institutions (could competent institution, institution of the State of residence or of the State of stay) Information regarding the insured event Kind of occupational disease (international classification of the disease) Date when the disease was first diagnosed Granted benefit Benefit was granted (Yes or No) Type of benefit granted Amount granted Period for which the benefit was granted Additional information Specific data DE - Germany doesn't use the international classification of the disease 9

283 I Italy use the European list of industrial disease Article 39 General data 1.1. Identification of person concerned 1.2. Identification of institutions (could be competent institution, institution of the State of residence or of the State of stay) Date that any claim to the other state s scheme was made Information concerning the degree of the previous or subsequent incapacity for work Information making it possible to determine whether the incapacity is the result of an accident at work within the meaning of the legislation applied by the institution in the other Member State Confirmation that the other Member State accepts that the accident/ disease rose out of the claimant s employment Date of accident or commencement of occupational disease in the other Member State Was there any benefit awarded concerning occupational disease or accident at work? Period during which it was awarded Additional information Specific data LT- Insert name, personal identification number, social insurance number, case number. BE- Occupational disease should be added in information in 2.3. PT- In case of occupational disease enter kind of disease PT- Give degree of incapacity for work CZ- Add reason for the worsening of the situation, documentation ( medical report), no need to consider age. RO- Identification of the person concerned: name, surname, personal identification number, sex, date of birth, address, citizenship, type of worker,(employee, self-employee, seasonal, civil servant, frontier worker. Article 40 General data 1.1. Identification of person concerned 1.2. Identification of institutions (could be competent institution, institution of the State of residence or of the State of stay) Claim and supporting document ( can be scanned) Copy of decision ( can be scanned document). 10

284 Additional information Specific data GR- All replies refer only to accidents at work as occupational diseases are not covered IT- Claim should be done according to the competent institution s legislation LT- Send documents directly to the competent institution or to the liaison body CZ- Additional information could be the same as that required for Invalidity and pensions 11

285 UNEMPLOYMENT BENEFITS For each business flow, data sets were identified by the group. The objective was to list all data that could be needed by each Member State in order to have a library of data for each business flow. Later on, this basic message should be represented by a dynamical message so that specificities of each Member State can appear automatically. Each piece of data is defined by a type: - Text : free txt to fill in - Date : dd/mm/yyy - Number - Currency : every currency of the previous Euro zone and current currency will be available (in order to build the history of unemployed person as far as possible) - Label : this type will be represented by a drop down menu to choose one value - Bool : Yes or No only - Check Box : a box to tick. Every message begins with essential common data: - The person concerned (Personal Identification Number - Surname / Family Name - Forename(s) - Date of Birth - etc. => to be validated by AHG on Identity Management). - The article of the Regulation on which basis the message is exchanged. - Labelling of the message. - The institution that has sent the message. - The institution that should receive the message. From business flow 15 on, these elements are separated (without consequences on the identification of the flow). Regarding justification, wherever any justification needed has been answered in the negative ("No"), it is not excluded that, in individual cases, additional documents might be needed. This is why it is necessary that one has the option of choosing for every single request whether or not additional documents are needed. Detailed data are available below (table of data by business flow). On the whole, every data seemed to be needed by at least one Member state. That is the reason why the group agreed to have a library of data on a native message that could be represented by dynamical views depending on needing of each Member state via EESSI System. [note, this requirement is similar to the pensions sector's] Explanations for Business flows and identification of main data Business Flow 1 Customer resident in competent state but previously insured in another (Articles 61(1) and 61(2)) When a person claims benefits in competent state and previous periods of insurance or employment completed under the legislation of other Member State need to be taken into

286 account, this business flow shall allow the competent state to aggregate periods of insurance, employment or self employment. Message 1.1 Notification of a benefit claim request for insurance record (Article 54 of Implementing Regulation) The competent state requests other Member State(s) to provide it with necessary information about the insurance history of the unemployed person in order to aggregate periods of insurance, employment or self employment. This message contains the data needed by the state of former activity to identify the unemployed person s records. Structure: Address of the person concerned in the country in which he/she is registering for benefits Last address of the person concerned in country of former residence Reference period for all data Period of insurance Period of insured employment Period of insured self employment Other period of insurance Detailed break down of period. Specificities of Norway: Norway needs to know whether the social security insurance has been paid or not. It needs a justification (income and tax statement or pay slip). Message 1.2 Notification of insurance record This message contains the information needed by the competent institution to aggregate and calculate entitlement. Structure: Reference period for all data Period of insurance Period of insured employment Period of insured self employment Other period of insurance => detailed break down of period. Specificities of Germany: Germany needs to know the average gross wage during the last six months. In connection with the discussion on flow 1 (exchange of insurance history) a question arose as to whether facts or events which are not insurance or employment periods but have some effect on entitlement to unemployment benefits, should be also exchanged via EESSI and whether they should be included in the data sets for flow 1. The group came to conclusion that with regard to the variation of these elements in national systems of Member States, these elements should not be included in the data set drafted by this group, unless they are recognised and required by a majority of Member States (e.g. reason for termination of the last employment). 2

287 However, this issue should be referred as a horizontal issue to the Task Force (i.e. as an exchange of necessary information which should be taken into account according to Art. 5 of Regulation 883/2004). Business flow 2 Customer resident in competent state but previously employed in another (Articles 62(3) and 54(1)) This business flow is used when the competent state calculates benefits based upon previous salary, and allows data on earnings to be exchanged. It could be triggered in connection with business flow 12 (frontier workers). Message 2.1 Notification of a benefit claim request for salary or professional income (Article 54 of Implementing regulation) The competent state asks for detailed information from the Member State where the unemployed person was previously insured in order to calculate benefits. Structure: Last address of the person concerned in country of former activity, if the person stayed in the country during his last activity Reference period Name and address of employer/place of business Employment or Self employment. Message 2.2 Notification of salary or professional income The Member State where unemployed person was previously insured sends back information. Structure: Reference period Detail of each employment or self-employment period and earnings for each period. Specificities: Austria needs to know the gross earnings which underlie unemployment insurance in the country where paid work is performed / which are used to determine the contributions paid. During the discussion on data sets for flows 1 and 2, the group also identified a need for exchange of some of the data necessary to prevent possible fraud in the field of unemployment benefits (e.g. concurrence of benefits with income from another Member State or overlapping of unemployment benefits from more Member States). The group decided to exchange this kind of information only in cases where the risk of such a fraud is considerable (e.g. cases of frontier workers) and to rely in other cases on the general flow for the exchange of information. This issue could also be further discussed within the new AHG combating frauds and errors which was founded at the last meeting of Administrative Commission in December Business flow 3 Customer resident in competent state but family resident in another (Article 62) 3

288 For some Member States, calculation of benefits varies with the number of members of family and their earnings. This business flow is a complement to calculate unemployment benefits for these Member States. Message 3.1 Notification of a benefit claim request for details of dependent family members (Article 54 (3) of Implementing regulation) The competent state asks for information about family members from each Member State in which a family member resides. Structure: Reference period Name and address of the office that the family members are registered with Details of any benefit claims made by the family members. Message 3.2 Notification of details of dependent family members The Member State replies and gives information. Structure: Detailed information on each family member Business flow 4 The unemployed person requests a document from the competent institution certifying that he/she retains entitlement to benefits (Article 55 (1) Impl. Reg.: request for the document that certifies the export of unemployment benefits) This business flow concerns only exchanges between one person and an institution. There is no data flow between Member States. Business flow 5 The unemployed person registers with the unemployment services of the assisting institution without having the document (Article 55 (2) Impl. Reg.) This business flow illustrates information that should have been on the document referred to in flow 4. Every data that could be needed to certify the export of unemployment benefits are illustrated there. If some event occurs that is likely to affect entitlement to benefits, such an event should be reported without undue delay. It should also apply to circumstances where only the start date is known, even though these circumstances would require a start and end date for reporting. Message 5.1 Request for the document certifying that the unemployed person retains entitlement to benefits under the conditions of Article 64 of Implementing Regulation The competent state requests information certifying the export of unemployment benefits. Structure: Date of registration Address of the unemployed person in the country in which he / she is seeking work Last address of the unemployed person in the competent state Name of the unemployment fund in charge in the competent state. 4

289 Message 5.2 Document certifying mentioned entitlement (Article 55 (1) of Implementing regulation) Detailed information is sent by Member State in order to certify the entitlement to export the benefits. Structure: Is there entitlement to the document? Address of the Institution paying the benefits Date on which the unemployed person ceased to be available to the employment service of the competent state Last day of the period granted in accordance with Art.64 (1) b) Reg. 883/04 in order to register as a person seeking work Last day of the maximum period during which the entitlement to benefits may be retained in accordance with Art. 64 (a) c) Reg. 883/04 Detailed circumstances or events likely to affect the entitlement to benefits. Specificity of Germany: Germany needs to notify to other Member states whether the unemployed person applied for a second document certifying the entitlement to unemployment benefits under a second German law. Business flow 6 The unemployed person registers with the unemployment services of the assisting institution (Article 55 (4) Impl. Reg.) This business flow is just a notification of registration with the assisting institution, in case of export of benefits. Message 6.1 Information of the date of the registration and of the new address of the unemployed person The assisting institution sends information to the institution of the competent state. Structure: Date of registration Address of the unemployed person in the country in which he / she is seeking work. Business flow 7 The assisting institution comes to know about circumstances likely to affect the entitlement to benefits (Article 55 (4) Impl. Reg.) In case of export of benefits, if circumstances likely to affect them occur, the assisting institution will inform the institution of the competent state about their nature. Message 7.1 Information without delay about the relevant information concerning the circumstances likely to affect the entitlement to benefits Without delay, the assisting institution sends information about circumstances likely to affect the entitlement to benefits. Structure: Detailed circumstances likely to affect the entitlement to benefits. 5

290 Message 7.2 Information about the effect of the circumstances to the entitlement to benefits optional, depends on answer If the assisting institution wants to know which consequence these circumstances have on the entitlement to benefits, it mentions it in the last data of the previous message. This message is the answer of the competent institution. Structure: Additional data for the information about the effect on the entitlement to UB Period of interruption. Business flow 8 The competent institution wants information concerning the follow-up of the unemployed person s situation (Article 55 (4) Impl. Reg.) In order to stay informed about the job-seeking activities of unemployed person, the competent state may need information concerning the follow-up of the unemployed person s situation from the assisting institution. This business flow illustrates exchanges of the follow-up. Message 8.1 Request for relevant information concerning the follow-up of the unemployed person s situation The competent state asks for information concerning the follow-up on a monthly basis. Structure: Is the unemployed person still registered with the employment services and complying with organized checking procedures? Message 8.2 On a monthly basis, information concerning the follow-up of the unemployed person s situation The assisting institution replies by Yes or No. Business flow 9 The unemployed person returns to the competent state before the period granted to search for work ends, and the competent institution has come to know that the unemployed person did not inform the assisting institution about his/her return to the competent state (Article 64 Reg. 883/04) In case of export of benefits, this business flow is just a notification of the competent institution that the unemployed person returned. Message 9.1 Notification of the returning of the unemployed person The competent state sends the date of return to the assisting institution. Structure: Date. Business flow 10 The competent institution extends the period granted to the unemployed person to export their unemployment benefits (Article 64 Reg. 883/04) 6

291 In case of export of benefits, the possibility is given to extend the granted period from 3 up to 6 months. This business flow is just a notification from the competent state to the assisting institution that it has extended the period granted to the unemployed person. Message 10.1 Notification of the extended of the period granted to the unemployed person to export their unemployment benefits The competent institution sends the new last date of maximum period during which the entitlement to benefits may be retained. Structure: New last date. Business flow 11 The entitlement to benefits terminates during the three (to six) month export period for any reason and the termination date is different from the previously certified date (Article 64 Reg. 883/04) In case of export, the entitlement to benefits may end before the previous date certified. The competent state shall inform as soon as possible the assisting institution of the new last date of ending of the entitlement. This business flow is just a notification of the modified date. Message 11.1 Notification of the entitlement to the unemployment benefits as soon as the entitlement terminates The competent state sends the modified date on which the entitlement to unemployment benefits ended. Structure: Modified date. Business flow 12 Person makes himself/herself available to the employment services in the Member State of residence (Art.65(2) first sentence of the Reg. 883/2004) This business flow is a compilation of flows 1 and 2 applicable in case of a frontier worker. The group decided to keep this special flow (instead of referring to flows 1 and 2) to cover particularities typical for exchange of data concerning frontier workers. Message 12.1 Request for the data necessary for calculating the UB Article 61 and 62 shall apply The Institution of Member State of residence needs some data to grant and calculate the unemployment benefits. It requests information from the Member State of previous activity. Structure: Address of the person concerned in the country in which he/she is registering for benefits Reference period Former address in the country of last activity, if the person has stayed in that country Period of insurance Period of insured employment Period of insured self employment 7

292 Other period of insurance => detailed break down of period. Message 12.2 Data provided The Member State of previous activity gives information. Structure: Last address of the person concerned in country of former residence Reference period The person is entitled to benefits under Regulation 883/2004 If yes, the period If no, the reason Period of insurance Period of insured employment Period of insured self employment Other period of insurance => detailed break down of period. Business flow 13 Person takes a supplementary step- he/she makes himself/herself available to the employment services of the Member State in which he/she pursued his/her last activity (Art.65(2) second sentence of Reg. 883/2004) This business flow concerns frontier workers who decide to make themselves available to the unemployment services of the Member State in which they pursued their last activity. It should allow the Institution of the Member State of residence to exchange information about registration and job seeking activities with the Member State of previous activity. Message 13.1 Request for information concerning the unemployed person s registration and search for employment in Member State B (Article 56 (1) last sentence) The institution of Member State of the last activity asks for information about registration and search for employment of the unemployed person. Structure: Request for information Reference period. Message 13.2 Information requested The institution of the Member State of residence sends information on registration and job-seeking activities. Structure: Date of registration Name and address of the employment office where the person registers Address of unemployed person in the Member State of residence Information on job-seeking activities (training, employment, interviews). Message 13.3 Request for information on the job seeking activities in the Member State of the last activity 8

293 The institution of Member State of residence needs information on job-seeking activities from the Member State of previous activity. Structure: Request for information Reference period. Message 13.4 Information on job-seeking activities The institution of Member State of previous activity sends information to the institution of Member State of residence. Structure: Date of registration Name and address of the employment office where the person registers Address of unemployed person in Member State of residence Period of training Number of applications for a job during period Unemployed person has taken up employment or has become self-employed. Business flow 14 Person who has been provided UB at the expense of the competent institution of the Member State to whose legislation he/she was last subject (Member State of the last activity) has decided to return to the Member State of residence (Art.65 (5) (b) of Reg. 883/2004, Art.56 (3) of the Implementing Regulation) In this business flow, an unemployed person returns to the Member State of residence and claims unemployment benefits there. The Member State of residence needs to have information on the entitlement to benefits from the Member State of previous activity. Message 14.1 Request for the information on the entitlement to UB under Article 64 of the Regulation 883/2004 The institution of Member State of residence asks for information on the entitlement to benefits from the institution of Member State of previous activity. Structure: Is there entitlement under Art. 64 of Reg. 883/2004? Date of registration Address of the unemployed person in the country in which he / she is resident Last address of the unemployed person in the state of last activity Name of the unemployment fund in charge in the competent state. Message 14.2 Information sent by Member State of the last activity to the Member State of residence The institution of Member State of previous activity provides this information. Structure: Information on the unemployment benefits under Art. 64. The five following flows concern the following situation of the Regulation 883/2004: 9

294 - A wholly unemployed person who, during his/her last activity as an employed or self-employed person, resided in a Member State other than the competent Member State and who continues to reside in that Member State or returns to that Member State shall make himself/herself available to the employment services in the Member State of residence. The Member state of residence can claim for reimbursement of unemployment benefits to the Member state of previous activity. Business flow 15 Reimbursement between Member States => Full acceptance of the request (Art.65(6) and 65(7) of Reg. 883/2004 Art. 66 and 69 of the Implementing Reg.) The Member State of residence claims reimbursement of unemployment benefits from the Member State of previous activity. The Member State of previous activity accepts fully the claim of reimbursement. Message 15.1 Request for reimbursement The Member State of residence claims reimbursement. Structure: Total amount which is requested Number of the single cases included in the reimbursement request Name and address of the bank and IBAN and SWIFT bank account numbers to which the amount should be remitted Detailed single case of reimbursement claim. Message 15.2 Full acceptance of the request The Member State of previous activity accepts fully the claim. Message 15.3 Confirmation of receiving the amount reimbursed The Member State of residence confirms it received the amount. Business flow 16 Reimbursement between Member States => Request for reimbursement is not accepted or is partially accepted (Art. 65 (6) of the Reg. 883/2004 and Art. 66 and Art. 69 of the Impl. Reg.) The Member State of residence claims reimbursement of unemployment benefits from the Member State of previous activity. The Member State of previous activity does not accept the claim of reimbursement or accepts it partially. Message 16.1 Request for reimbursement Same as message Message 16.2 Information about non-acceptance or partially acceptance The Member State of previous activity does not accept the claim of reimbursement or accepts it partially and gives reasons for this decision. 10

295 Structure: Details of reason on whole claim Details of reason on each single case. Business flow 17 Request for reimbursement is not accepted or is partially accepted, clarification of disputes and objections - Art. 65 (6) of the Reg. 883/2004 and Art. 66 and Art. 69 of the Impl. Reg. The Member State of previous activity does not accept the claim of reimbursement or accepts it partially. The Member State of residence asks for clarification. Message 17.1Decision to reject some expenditures Art.66 of the Impl. Reg. Same as message Message 17.2 Response The Member State of residence does or does not accept the decision on non-acceptance or partial acceptance. Structure: Information on whole claim Information on each single case. Message 17.3 Further clarification of the objections Same as message 17.2 Business flow 18 Reimbursement between Member States => Possibility of charging interest - Art. 65 (6) and 65 (7) of the Reg. 883/2004 and Art. 67 of the Impl. Reg. The Member State of previous activity did not reimburse in time and the Member State of residence decides to charge interest. Message 18.1 Information about the decision whether interest will be charged or not The Member State of residence informs about decision to charge interest. Structure: Reimbursement claim identification Date on which the payment was due Period interest is charged for Interest rate Total amount of interest charged Details of each single case for which interests are charged. Message 18.2 Response The Member State of previous activity informs if it agrees or not to this charging of interest. 11

296 Business flow 19 Reimbursement between Member States => Closing flow - Art. 65 (6) and 65 (7) of the Reg. 883/2004 and Art. 67 of the Impl. Reg. This business flow closes the reimbursement request. Message 19.1 The information about amount reimbursed (carrying out the reimbursement) The Member State of previous activity informs about the reimbursement. Structure: Total amount which is reimbursed Name and address of the bank. Message 19.2 Confirmation of receiving the amount reimbursed The Member State of residence confirms to the Member State of previous activity the receipt of reimbursement. Structure: The date on which the crediting party (institution) received the payment of reimbursements We consider this case of reimbursements as closed. Message 19.3 Confirmation of receiving the amount reimbursed The Member State of previous activity confirms it also considers this case closed. 12

297 Table of data by business flows This is the list of data on which every member of the group agreed. Some specificities appear in flows 1 and 5. Flow 1 Data element Type of data Message 1.1 : Notification of a benefit claim request for insurance record (Article 54 of implementing regulation) Essential common elements (5 items) Text Address of the person concerned in the country in which he/she is registering for benefits Text Last address of the person concerned in country of former residence Text Reference period for all data From Date To Date Period of insurance Period of insured employment Label Period of insured self employment Label Other period of insurance Label Period of employment or Self employment Period From Date To Date Type Employment Label Self Employment Label Employment that is not insurance period Label Self employment that is not insurance period Label Name and address of employer Text Nature of employment Text Reason for termination Dismissal by the employer Label Resignation by the employee Label Expiry of contract Label Termination of contract by mutual consent Label Dismissed for disciplinary reason Label Redundancy Label Other Label Reason of termination of Self employment Text In case of self employment not treated as insurance period, earnings Number / Currency In case of self employment not treated as insurance period, number of hours Number Period of Sickness Period From Date To Date Period of maternity or Period looking after children Period From Date To Date Period of deprivation of liberty Period From Date To Date Period of Education Period From Date To Date Period of Military or alternative civilian service Period From Date To Date Other Periods Period From Date To Date Type Text Name and address of insurance company Text Nature of activity during period not covered Text Period of Unemployment benefits Period From Date To Date Name and address of local agency for employment or local institution for benefits Text Identification number 13

298 Message 1.2 : Notification of insurance record Data element Type of data Essential common elements (5 items) Text Reference period From Date To Date Period of insurance Period of insured employment Label Period of insured self employment Label Other period of insurance Label Period of employment or Self employment Period From Date To Date Type Employment Label Self Employment Label Name and address of employer Text Nature of employment Text Reason for termination Dismissal by the employer Label Resignation by the employee Label Expiry of contract Label Termination of contract by mutual consent Label Dismissed for disciplinary reason Label Redundancy Label Other Label Reason of termination of Self employment Text Period that is not period of insurance Type Employment that is not insurance period Label Self employment that is not insurance period Label Period of employment not insured period From Date To Date Gross earnings Number / Currency Period of employment not insured period From Date To Date Number of hours Number Period of self employment not insured period From Date To Date Gross earnings Number / Currency Period of self employment not insured period From Date To Date Number of hours Number Hours of work per month Number State amount when "termination of contract" Number / Currency Period of Sickness Period From Date To Date Period of maternity or Period looking after children Period From Date To Date Period of deprivation of liberty Period From Date To Date Period of Education Period From Date To Date Period of Military or alternative civilian service Period From Date To Date Other insurance periods Period From Date To Date Type Period of voluntarily continued insurance Label Period treated as a period of insurance Label Compensation for vacation not taken Label Period of compensation for vacation not taken From Date 14

299 Flow 2 Data element Type of data Message 2.1 : Notification of a benefit claim request for salary or professional income (Article 54 of implementing regulation) Essential common elements (5 items) Last address of the person concerned in country of former activity, if the person stayed in the country during his last activity Reference period From Date To Date Name and address of employer/place of business Text Employment Yes / No Bool Self employment Yes / No Bool Message 2.2 : Notification of salary or professional income Essential common elements (5 items) Text Reference period From Date To Date Employment Period From Date To Date Earnings Periodicity Lump sum (e.g. bonus) Label Weekly Label Monthly Label Period From Date To Date Earnings during reference period Gross Number / Currency* Net Number / Currency* Specificities of Austria, Germany and Norway Number / Currency* Other payments Single payments Number / Currency* Extra payment for overtime Number / Currency* Compensation for lost of office Number / Currency* Compensation for vacation not taken Number / Currency* Others Number / Currency* Number of hours worked during this period Number These data must be completed for each salary Text Text 15

300 Flow 3 Data element Type of data Message 3.1 : Notification of a benefit claim request for details of dependent family members (Article 54 (3) of implementing re Essential common elements (5 items) Text Reference period From Date To Date Name and address of the office that the family members are registered with Text Details of any benefit claims made by the family members Text Family members Full ID details Address If children, Full ID details of the person taking care of children Text Text Text Message 3.2 : Notification of details of dependent family members Essential common elements (5 items) Text Family members Period From Date To Date Family member Parent Label Partner Label Child Label Brother / Sister Label Other Label Full ID details Text Whether any other person is entitled to unemployment benefits calculated on the basis of the same family member Yes / No Text Family member benefits or other earnings Number / Currecny If child, is he under education? Yes / No Bool Flow 4 No data exchanged 16

301 Flow 5 Data element Type of data Message 5.1 : Request for the document certifying that the unemployed person retains entitlement to benefits under the conditions of Art. 64 Reg. 883/2004 Essential common elements Date of registration Address of the unemployed person in the country in which he / she is seeking for work Last address of the unemployed person in the competent state Name of the unemployment fund in charge in the competent state Text Date Text Text Text Message 5.2 : Document certifying mentioned entitlement (Art. 55 n 1 Implementation regulation) Essential common elements Text Is there entitlement to the document? Yes (next data will have to be filled in) Text No (the flow will end) Text Address of the Institution paying the benefits Text Date on which the unemployed person ceased to be available to the employment service of the competent state Date Last day of the period granted in accordance with Art.64 (1) b) Reg. 883/04 in order to register as a person seeking work Date Last day of the maximum period during which the entitlement to benefits may be retained in accordance with Art. 64 (a) c) Reg. Date 883/04 Circumstance likely to affect the entitlement to benefits Single event likely to affect the entitlement to benefits Starting date Date Single event likely to affect the entitlement to benefits The unemployed person has taken up employment or becomes self-employed Label The unemployed person receives earnings from an activity other than those mentioned in item 1 above Label The unemployed person refuses an offer of employment or refuses to go for an interview with the employment services Label The unemployed person refuses to participate in occupational rehabilitation Label The unemployed person is suffering from incapacity for work Label Event likely to affect the entitlement to benefits Period From Date To / Still on going Date Circumstance likely to affect the entitlement to benefits The unemployed person does submit to control procedures Label The unemployed person is not available to the employment services Label Flow 6 Data element Message 6.1 : Information of the date of the registration and of the new address of the unemployed person Essential common elements Date of registration Address of the unemployed person in the country in which he / she is seeking for work Type of data Text Date Text 17

302 Flow 7 Data element Type of data Message 7.1 : Information without delay about the relevant information concerning the circumstances likely to affect the entitlement to benefits Essential common elements Circumstance likely to affect the entitlement to benefits Single event likely to affect the entitlement to benefits Starting date Single event likely to affect the entitlement to benefits The unemployed person has taken up employment or becomes self-employed The unemployed person receives earnings from an activity other than those mentioned in item 1 above The unemployed person refuses an offer of employment or refuses to go for an interview with the employment services The unemployed person refuses to participate in occupational rehabilitation The unemployed person is suffering from incapacity for work Text Date Label Label Label Label Label Event likely to affect the entitlement to benefits Period From Date To Date Circumstance likely to affect the entitlement to benefits The unemployed person does not submit to control procedures Label Notification whether the competent institution should inform the assisting institution about the effect of the circumstances to the entitlement of benefits to UB The unemployed person is not available to the employment services Yes (fill out next data) No (end of the flow) Message 7.2 : Information about the effect of the circumstances to the entitlement to benefits - optional, depends on answer Essential common elements Text Additional data for the information about the effect to the entitlement to UB The basic entitlement to UB is terminated Label The basic entitlement to UB is not affected Label The basic entitlement to UB is interrupted Label Period of interruption From Label To/ Still on going Label Unknown Check Box Label Label Label Flow 8 Data element Message 8.1 : Request for relevant information concerning the follow-up of the unemployed person's situation Essential common elements Type of data Text Is Is the unemployed person still registred with the employment services and complying with organized checking procedures? On a monthly basis Text Message 8.2 : On a monthly basis, information concerning the follow-up of the unemployed person's situation Essential common elements Is the unemployed person still registred with the employment services and complying with organized checking procedures? Yes No Text Label Label Flow 9 Data element Message 9.1 : Notification of the returning of the unemployed person Essential common elements Date on which the unemployed person returned to the competent state or registered with the competent institution Type of data Text Date Flow 10 18

303 Data element Type of data Message 10.1 : Notification of the extended of the period granted to the unemployed person to export their unemployment benefits Essential common elements The new last date of the maximum period during which the entitlement to benefits may be retained in accordance with art.64 (a) c) Reg. 883/04 Text Date Flow 11 Data element Type of data Message 11.1 : Notification of the entitlement to the unemployment benefits as soon as the entitlement terminates Essential common elements The modified date on which the entitlement to unemployment benefits ended Text Date 19

304 Flow 12 Data element Message 12.1 : Request for the data necessary for calculating the UB - Art. 61 and 62 shall apply Type of data Essential common elements (5 items) Text Address of the person concerned in the country in which he/she is registering for benefits Text Reference period From Date To Date Former address in the country of last activity, if the person has stated in that country Period of insurance Period of insured employment Label Period of insured self employment Label Other period of insurance Label Period of employment or Self employment Period From Date To Date Type Employment Label Self Employment Label Employment that is not insurance period Label Self employment that is not insurance period Label Name and address of employer Text Nature of employment Text Reason for termination Dismissal by the employer Label Resignation by the employee Label Expiry of contract Label Termination of contract by mutual consent Label Dismissed for disciplinary reason Label Redundancy Label Other Label Reason of termination of Self employment Text In case of self employment not treated as insurance period, earnings Number / Currency In case of self employment not treated as insurance period, number of hours Number Period of Sickness Period From Date To Date Period of maternity or Period looking after children Period From Date To Date Period of deprivation of liberty Period From Date To Date Period of Education Period From Date To Date Period of Military or alternative civilian service Period From Date To Date Other Periods Period From Date To Date Type Text Name and address of insurance company Text Nature of activity during period not covered Text Period of Unemployment benefits Period From Date To Date Name and address of local agency for employment or local institution for benefits Text Identification number Text 20

305 Message 12.2 : Data provided Data element Type of data Essential common elements (5 items) Text Last address of the person concerned in country of former residence Text Reference period From Date To Date The person is entitled to benefits under Regulation 883/2004 Yes / No Bool If yes, the period From Date To Date If no, the reason No entitlement under legislation of the institution issuing this message Label Person failed to apply for export of benefits correctly Label Period of insurance Period of insured employment Label Period of insured self employment Label Other period of insurance Label Period of employment or Self employment Period From Date To Date Type Employment Label Self Employment Label Name and address of employer Text Nature of employment Text Reason for termination Dismissal by the employer Label Resignation by the employee Label Expiry of contract Label Termination of contract by mutual consent Label Dismissed for disciplinary reason Label Redundancy Label Other Label Reason of termination of Self employment Text Elements to calculate the date of start of the benefits Text The person has received or has still to receive wages for the Number / Amount period following termination of work, up to Currency The person has received or has still to receive, on termination of work, compensation or other similar payments, amounting to Amount Number / Currency Has received or has still to receive payment in lieu of annual leave, amounting to. For.. Days The person has waived the following rights he enjoys under his contract of employment The person is in receipt of other benefits Amount Number of days Yes No Reason Number / Currency Number Period that is not period of insurance Type Employment that is not insurance period Label Self employment that is not insurance period Label Period of employment not insured period From Date To Date Gross earnings Number / Currency Period of employment not insured period From Date To Date Number of hours Number Period of self employment not insured period From Date To Date Gross earnings Number / Currency Period of self employment not insured period From Date To Date Number of hours Number Hours of work per month Number State amount when "termination of contract" Number / Currency Period of Sickness Period From Date To Date Label Label Text Text 21

306 Period of maternity or Period looking after children Period From Date To Date Period of deprivation of liberty Period From Date To Date Period of Education Period From Date To Date Period of Military or alternative civilian service Period From Date To Date Other insurance periods Period From Date To Date Type Period of voluntarily continued insurance Label Period treated as a period of insurance Label Compensation for vacation not taken Label Period of compensation for vacation not taken From Date To Date Amount Number / Currency Other activity during period Text Period of Unemployment benefits Period From Date To Date 22

307 Flow 13 Data element Type of data Message 13.1 : Request for information concerning the unemployed person's registration and search for employment in MS B - Art last sentence Essential common elements (5 items) Text Request for information Text Reference period From Date to Date Message 13.2 : Information requested Essential common elements Text Date of registration Date Name and address of the employment office where the person registers Text Address of unemployed person in Member State B Text Is the jobseeker following a training? Yes Label No Label Not known Label If Yes From Date To Date Not known Check Box The date of the next appointment at the job centre office Date Date Unknown date Check Box Unemployed person has taken up employment or has become selfemployed From Date To Date Unknown date Check Box Unemployed person is not available to the employment services From Date To Unknown date Message 13.3 : Request for information on the job-seeking activities in the MS of the last activity Date Check Box Essential common elements Text Request for practical information on job-seeking activities Text Reference period From Date to Date Message 13.4 : Information on job-seeking activities Essential common elements Text Date of registration Date Name and address of the employment office where the person registers Text Address of unemployed person in Member State B Text Period of training From Date To Date Not known Label Number of applications for a job during period Number Number Not known Check Box Unemployed person has taken up employment or has become selfemployed From Date To Date Unknown date Check Box Flow 14 Data element Message 14.1 : Request for the information on the entitlement to UB under Art. 64 of the Reg. 883/2004 Essential common elements Is there entitlement under Art. 64 of the Reg. 883/2004? Date of registration Address of the unemployed person in the country in which he / she is resident Last address of the unemployed person in the state of last activity Name of the unemployment fund in charge in the competent state Type of data Text Text Date Text Text Text Message 14.2 : Information sent by MS of the last activity to the MS of residence Essential common elements The unemployed person is entitled to unemployment benefits under Art. 64 Yes (Data of flow 5.2 will have to be filled in) No (the flow will end) Text Label Label 23

308 Flow 15 Message 15.1 : Request for reimbursement Data element Type of data The article of the Regulation on which basis the message is exchanged Labelling of the message The institution that has sent the message The institution that should receive the message Total amount which is requested Number of the single cases included in the reimbursement request Name and address of the bank and IBN and SWIFT bank account numbers to which the amount should be remitted Text Text Text Text Number / Currency Number Text Single case The person concerned (data element 0.1 of the essential common elements) Text Sequential number Number Identification data of the client as listed in the insurance record in which the last period taken into account was certified Number Period for which the UB was paid From Date To Date Name and address of the Institution certifying insurrance records Date on which the entitlement to UB begins End of the period for which the reimbursement is requested (maximum 3 or 5 month) Date of last payment, at the same time key date for defining the exchange rate for the reimbursement Amount of the payment for the requested period Message 15.2 : Full acceptance of the request Text Date Date Date Number / Currency YES we accept your request for reimbursement as you have sent it Text Message 15.3 : Confirmation of receiving the amount reimbursed YES we received the amount Text 24

309 Flow 16 Message 16.1 : Request for reimbursement refers to message 15.1 Data element Type of data Message 16.2 : Information about non-acceptance or partially acceptance Whole claim Non acceptance Yes (reason has to be filled in) Label No (flow ends) Label Reason of NON ACCEPTANCE Text The reimbursement claim for <free text> was submitted after the time limit, Art. 69 Par. 2 Impl. Reg. Yes / No Bool Partial acceptance Yes ("single case" have to be filled in) Label No (Flow will end) Label Single case Sequential number linked to the reimbursement claim Number Non acceptance Non acceptance of this single case Yes (reason has to be filled in) Label No Label Reason Text The reimbursement claim for <free text> was submitted after the time limit, Art. 69 Par. 2 Impl. Reg. Yes / No Bool The amount payable under the legislation of the state of last Yes / No activity would have been zero (Art. 65 Par. 6 S. 3 Reg. 883/2004). - Bool Partial acceptance Partial acceptance of single case Yes (reason has to be filled in) Label No Label Reason Text The amount payable under the legislation of the state of last activity would have been only < amount in the currency of the member state of residence>. This amount will be reimbursed. The Yes / No Bool remaining amount will not be reimbursed. Art. 65 Par. 6 S. 3 Reg. 883/2004 The statements concerning the amount of the reimbursement claim for the single case is wrong. The reimbursement case has to Yes (reason has to be filled in) Label be submitted again with the correct amount. No Label Reason Text The reimbursement for a period of 5 month is not justified (less than 12 month from the state of last activity were taken into Yes / No Bool account), Art. 65 Par. 7 Reg. 883/2004. Others Text The statements for the reimbursement case are not complete. The reimbursement case has to be submitted again completely. No Reason <free text> to give information concerning the missing data for the reimbursement case - Mandatory Other reasons for objection: Yes (reason has to be filled in) Label Label Text Text Text 25

310 Flow 17 Data element Message 17.1 : Decision to reject some expenditures Art.66 of the Impl. Reg. refers to message 16.2 Type of data Message 17.2 : Information about non-acceptance or partially acceptance Whole claim We agree Yes (the flow will end) Label No (reason will have to be filled in) Label Reason Text Single case Sequential number Number We agree Yes (the flow will end) Label No (reason will have to be filled in) Label Reason Text Message 17.3 : Further clarification of the objections refers to message 17.2 Message 17.4 : Further clarification of the objections refers to message 17.2 Flow 18 Data element Message 18.1 : Information about the decision whether interest will be charged or not Type of data The article of the Regulation on which basis the message is exchanged Text Labelling of the message Text The institution that has sent the message Text The institution that should receive the message Text Reimbursement claim identification and date on which the payment was due Number Date on which the payment was due Date The interests will be charged Yes (next data will have to be filled in) Label No (the flow will end) Label Period interest is charged for From Date To Date If yes, interest rate Number If yes, total amount of interest charged Number Single case on which interests will be charged The person concerned (data element 0.1 of the essential common elements) Text Sequential number Number Amount (basis) on which the interest is charged Number / Currency Amount of interest for this case Number / Currency Period interest is charged for From Date To Date The interests will be charged Yes / No Bool If yes, interest rate Number / Currency Message 18.2 : Response We agree Yes Label No Label If no Reason Text 26

311 Flow 19 Data element Message 19.1 : The information about amount reimbursed (carrying out the reimbursement) Identification of the reimbursement request The article of the Regulation on which basis the message is exchanged Labelling of the message The institution that has sent the message The institution that should receive the message Total amount which is reimbursed Name and address of the bank Type of data Number Text Text Text Text Number / Currency Text Message 19.2 : Confirmation of receiving the amount reimbursed The date on which the crediting party (institution) received the payment of reimbursements Date We consider this case of reimbursements as closed Yes / No Bool Message 19.3 : Confirmation of receiving the amount reimbursed We consider this case of reimbursements as closed Yes / No Bool 27

312 List of justifications for each member state Member States who do not need any justification do not appear in this table. Austria Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Self employment that is not insurance period Scanned Document sufficient document Message 1.1 Employment Other reason or Reason of termination of Self employment Scanned Document sufficient paper Message 1.1 Other Type Presence abroad of a consequence of the applicant accompanying her or his spouse in Scanned Document sufficient document connection with her or his work abroad Message 1.1 Other Period of voluntarily continued insurance (name will have to be filled in under) Scanned Document sufficient document Message 1.1 Other Period treated as a period of insurance Scanned Document sufficient document Message 1.1 Other Activity during period not otherwise covered (nature will have to be filled in under) Scanned Document sufficient document Message 12.1 Employment Self employment that is not insurance period Scanned Document sufficient document Message 12.1 Employment Other reason or Reason of termination of Self employment Scanned Document sufficient paper Message 12.1 Other Type Presence abroad of a consequence of the applicant accompanying her or his spouse in Scanned Document sufficient document connection with her or his work abroad Message 12.1 Other Period of voluntarily continued insurance (name will have to be filled in under) Scanned Document sufficient document Message 12.1 Other Period treated as a period of insurance Scanned Document sufficient document Message 12.1 Other Activity during period not otherwise covered (nature will have to be filled in under) Scanned Document sufficient document Message 15.1 Single case Amount of the payment for the requested period Scanned Document passendes Dokument Message 18.1 Single case on which interests will be charged Amount of interest for this case Scanned Document nachvollziehbare Berechnung 28

313 Belgium Message Object Subobject Data element Type of justification Nature C4-document (only for periods of Message 1.1 Employment Type Employment that is insurance period Scanned Document employment not yet declared to the belgian national office of social security - e.g. C4 ('s) for the last 3 months) Message 1.1 Employment Employment that is not insurance period Scanned Document C4-document Message 1.1 Employment Reason for termination Dismissal by the employer Scanned Document C4-document (only for the last employment) Message 1.1 Employment Resignation by the employee Scanned Document C4-document (only for the last employment) Message 1.1 Employment Expiry of contract Scanned Document C4-document Message 1.1 Employment Termination of contract by mutual consent Scanned Document C4-document Message 1.1 Employment Dismissed for disciplinary reason Scanned Document C4-document Message 1.1 Employment Other (reason will have to be filled in) Scanned Document C4-document Message 12.1 Employment Type Employment that is insurance period Scanned Document C4-document (only for periods of employment not yet declared to the belgian national office of social security - e.g. C4 ('s) for the last 3 months) Message 12.1 Employment Employment that is not insurance period Scanned Document C4-document Message 12.1 Employment Reason for termination Dismissal by the employer Scanned Document C4-document (only for the last employment) Message 12.1 Employment Resignation by the employee Scanned Document C4-document (only for the last employment) Message 12.1 Employment Expiry of contract Scanned Document C4-document Message 12.1 Employment Termination of contract by mutual consent Scanned Document C4-document Message 12.1 Employment Dismissed for disciplinary reason Scanned Document C4-document Message 12.1 Employment Other (reason will have to be filled in) Scanned Document C4-document Bulgaria Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Paper copy Work book Message 1.1 Employment Type Self employment that is insurance period Paper copy Insurance history book Message 1.1 Employment Type Employment that is not insurance period Paper copy Work book Message 1.1 Employment Type Self employment that is not insurance period Paper copy Insurance history book Message 12.1 Employment Type Employment that is insurance period Paper copy Work book Message 12.1 Employment Type Self employment that is insurance period Paper copy Insurance history book Message 12.1 Employment Type Employment that is not insurance period Paper copy Work book Message 12.1 Employment Type Self employment that is not insurance period Paper copy Insurance history book Czech Republic Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Name and address of employer Scanned Document potvrzení o zaměstnání Message 1.1 Maternity Scanned Document rodný list Message 12.1 Maternity Scanned Document rodný list Cyprus Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Scanned Document certificate from competent institution Message 1.1 Employment Type Employment that is not insurance period Scanned Document certificate from competent institution Message 1.1 Employment Reason for termination Dismissal by the employer Scanned Document Employer Declaration Message 1.1 Employment Reason for termination Resignation by the employee Scanned Document Employer Declaration Message 1.1 Employment Reason for termination Expiry of contract Scanned Document Employer Declaration Message 1.1 Employment Reason for termination Dismissed for disciplinary reason Scanned Document Employer Declaration, Employee Declaration Message 1.1 Sickness Scanned Document Medical Report Message 1.1 Maternity Scanned Document Certificate from Comprtent Institution Message 1.1 Deprivation of liberty Scanned Document Certificate from Competent Institution Message 5.1 Address of the unemployed person in the country in which he / she is seeking for work Scanned Document Message 5.1 Name of the unemployment fund in charge in the competent state Scanned Document Message 11.1 The modified date on which the entitlement to unemployment Scanned Document certificate from assisting institution benefits ended Message 12.1 Employment Type Employment that is insurance period Scanned Document certificate from competent institution Message 12.1 Employment Type Employment that is not insurance period Scanned Document certificate from competent institution 29

314 Denmark Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Scanned Document Form E 301 Message 1.1 Employment Type Employment that is not insurance period Scanned Document Form E 301 Message 1.1 Sickness Paper copy Message 6.1 Date of registration Scanned Document Electronical registration in the jobcenter database Message 9.1 Message 11.1 Date on which the unemployed person returned to the competent state or registered with the competent institution The modified date on which the entitlement to unemployment benefits ended Paper copy Paper copy Form E 303/5 Message 15.1 Total amount which is requested Paper copy Form E 303/4 Message 15.1 Message 15.1 Message 15.1 Message 15.1 Message 15.1 Message 15.1 Single case Single case Single case Single case Single case Name and address of the bank and IBN and SWIFT bank account numbers to which the amount should be remitted Name and address of the Institution certifying insurrance records Date on which the entitlement to UB begins End of the period for which the reimbursement is requested (maximum 3 or 5 month) Date of last payment, at the same time key date for defining the exchange rate for the reimbursement Amount of the payment for the requested period Date on which the payment was due Paper copy Original Form E 303/4 Original Form E 303/0-3 Original Original Form E 303/4 Original Form E 303/4 Paper doc is not in use, as justification is being carried out electronically in the database in the local Danish jobcenter Letter of request from the relevant MSinstitution Message 18.1 Paper copy E-form Message 18.1 If yes, interest rate Paper copy Corr with MS-inst. Message 18.1 If yes, total amount of interest charged Paper copy Corr with MS-inst. Message 18.1 Message 18.1 Message 18.1 Message 18.1 Single case on which interests will be charged Single case on which interests will be charged Single case on which interests will be charged Single case on which interests will be charged Period for which the UB was paid From Paper copy E 303/4 Period for which the UB was paid To Paper copy E 303/4 Amount (basis) on which the interest is charged Paper copy Form E 303/4 and letter of request form the rel. MS-inst. E-form Amount of interest for this case Paper copy E-form Message 19.1 Total amount which is reimbursed Original E 303/4 Message 19.1 Message 19.1 Period for which the From unemployment benefits were paid Original E 303/4 Period for which the To unemployment benefits were paid Original E 303/4 Message 19.2 The date on which the crediting party (institution) received the payment of reimbursements Paper copy Letter from the relevant MS-inst. Estonia Message Object Subobject Data element Type of justification Nature Message 10.1 The new last date of the maximum period during which the entitlement to benefits may be Paper copy certificate of the competent institution retained in accordance with art.64 (a) c) Reg. 883/04 Message 11.1 The modified date on which the entitlement to unemployment Paper copy certificate of the competent institution benefits ended Message 12.1 Employment Type Employment that is not insurance period Paper copy ceritficate from the empolyer (tööandja tõend), employment agreement (tööleping), employment record book (tööraamat) to cerificate periods of employment before Message 13.1 Request for information Message 14.1 Is there entitlement under Art. 64 of the Reg. 883/2004? Germany 30

315 Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Scanned Document "Arbeitsbescheinigung" Message 1.1 Employment Type Self employment that is insurance period Scanned Document "Beitragsnachweis" Message 1.1 Employment Type Employment that is not insurance period Scanned Document "Arbeitsbescheinigung" Message 1.1 Employment Type Self employment that is not insurance period Scanned Document "geeignete Nachweise, so vollständig wie möglich" Message 1.1 Sickness Scanned Document "Bescheid der Krankenkasse oder des Rentenversicherungsträgers" Message 1.1 Maternity Scanned Document "Bescheid des Trägers, der die Leistungen erbracht hat" Message 1.1 Deprivation of "Arbeitsbescheinigiung der Scanned Document liberty Justizvollzugsanstalt" Message 1.1 Message 1.1 Message 1.1 Military or alternative civilian service Military or alternative civilian service Unemployme nt benefits Period From Scanned Document Period To Scanned Document Name and address of local agency for employment or local institution for benefits Scanned Document "Wehrdienstbescheinigung" or "Zivildienstbescheinigung" "Wehrdienstbescheinigung" or "Zivildienstbescheinigung" "Bescheid des Trägers, der die Leistungen bei Arbeitslosigkeit erbracht hat" Message 1.1 Other Type Presence abroad of a consequence of the applicant accompanying her or his spouse in Scanned Document "geeigneter Nachweis" connection with her or his work abroad Message 1.1 Other Type Period of voluntarily continued insurance (name will have to be filled in under) Scanned Document "Beitragsnachweis" Message 1.1 Other Type Activity during period not otherwise covered Scanned Document "geeigneter Nachweis" Message 2.1 Nature of self employment/ Employment Nature of self employment/ Employment for emloyed persons: "Arbeitsbescheinigung" / for self emloyed: "geeignete Nachweise, so vollständig wie möglich" Flow 12 Flow 12 will be restructured and will mainly refer to flow 1 and flow 2. Please consider the justification needed as stated under flow 1 and 2. Message 14.1 Is there entitlement under Art. 64 of the Reg. 883/2004? Scanned Document Message 15.1 Single case Scanned Document Insurance record "Bescheid des Trägers des ehemaligen Beschäftigungsstaates, der die Leistungen bei Arbeitslosigkeit erbringt" 31

316 Hungary Message Object Subobject Data element Type of justification Nature Message 1.1 Address of the person concerned in the country in which he/she is registering for benefits Paper copy addres card Message 1.1 Employment Type Employment that is insurance period Paper copy certification for the establishment of unemployment benefit Message 1.1 Employment Self employment that is insurance period Paper copy tax certification Message 1.1 Employment Reason for termination Dismissal by the employer Paper copy certification for the establishment of unemployment benefit Message 1.1 Employment Resignation by the employee Paper copy certification for the establishment of unemployment benefit Message 1.1 Employment Expiry of contract Paper copy certification for the establishment of unemployment benefit Message 1.1 Employment Termination of contract by mutual consent Paper copy certification for the establishment of unemployment benefit Message 1.1 Employment Dismissed for disciplinary reason Paper copy certification for the establishment of unemployment benefit Message 1.1 Employment Other (reason will have to be filled in) Paper copy certification for the establishment of unemployment benefit Message 5.1 Date of registration Paper copy határozat Message 5.1 Address of the unemployed person in the country in which he / she is seeking for work Paper copy adress card Message 5.1 Last address of the unemployed person in the competent state Paper copy address card Message 6.1 Date of registration Paper copy határozat (resolution) Message 6.1 Address of the unemployed person in the country in which he Paper copy address card / she is seeking for work Message 7.1 Starting date of circumstances likely to effect the entitlement to benefits From Paper copy határozat (resolution) Message 8.1 Message 10.1 Message 11.1 Message 12.1 Is Is the unemployed person still registred with the employment services and complying with organized checking procedures? The new last date of the maximum period during which the entitlement to benefits may be retained in accordance with art.64 (a) c) Reg. 883/04 The modified date on which the entitlement to unemployment benefits ended Address of the person concerned in the country in which he/she is registering for benefits On a monthly basis Paper copy határozat (resolution) Paper copy Paper copy Paper copy határozat (resoluton) határozat (resolution) addres card Message 12.1 Employment Type Employment that is insurance period Paper copy certification for the establishment of unemployment benefit Message 12.1 Employment Self employment that is insurance period Paper copy tax certification Message 12.1 Employment Reason for termination Dismissal by the employer Paper copy certification for the establishment of unemployment benefit Message 12.1 Employment Resignation by the employee Paper copy certification for the establishment of unemployment benefit Message 12.1 Employment Expiry of contract Paper copy certification for the establishment of unemployment benefit Message 12.1 Employment Termination of contract by mutual consent Paper copy certification for the establishment of unemployment benefit Message 12.1 Employment Dismissed for disciplinary reason Paper copy certification for the establishment of unemployment benefit Message 12.1 Employment Other (reason will have to be filled in) Paper copy certification for the establishment of unemployment benefit Message 13.1 Request for information Paper copy Message 14.1 Is there entitlement under Art. 64 of the Reg. 883/2004? Paper copy határozat (resolution) Message 15.1 Total amount which is requested Paper copy határozat (resolution) Message 15.1 Message 15.1 Number of the single cases included in the reimbursement request Name and address of the bank and IBN and SWIFT bank account numbers to which the amount should be remitted Paper copy Paper copy határozat (resolution) határozat (resolution) 32

317 Italy Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Scanned Document Attestazione di lavoro dipendente Message 1.1 Sickness Scanned Document Certificato medico + Certificazione della ridotta capacità lavorativa + Attestazione dei periodi di malattia retribuiti Message 1.1 Deprivation of liberty Scanned Document Attestazione di lavboro dipendente Message 2.1 Nature of Self employment/employment Scanned Document Certificazione del datore di lavoro Message 6.1 Date of registration Message 6.1 Address of the unemployed person in the country in which he / she is seeking for work Message 7.1 Message 8.1 Message 9.1 Message 10.1 Message 11.1 Starting date of circumstances likely to effect the entitlement to benefits Is Is the unemployed person still registred with the employment services and complying with organized checking procedures? Date on which the unemployed person returned to the competent state or registered with the competent institution The new last date of the maximum period during which the entitlement to benefits may be retained in accordance with art.64 (a) c) Reg. 883/04 The modified date on which the entitlement to unemployment benefits ended From On a monthly basis Scanned Document Scanned Document Scanned Document Scanned Document Scanned Document certificazioni delle circostanze incidenti il diritto certificazione delle procedure di controllo previste certificazione del restante peeriodo certificazione della motivazione della estensione del diritto certificazione della motivazione della estensione del diritto Message 12.1 Employment Type Employment that is insurance period Scanned Document attestazione di lavoro dipendente Message 12.1 Sickness Scanned Document Certificato medico + Certificazione della ridotta capacità lavorativa + Attestazione dei periodi di malattia retribuiti Message 12.1 Deprivation of liberty Scanned Document Attestazione di lavboro dipendente Message 13.1 Request for information Scanned Document periodo dal al delle informazioni richieste e riferimenti legislativi Message 13.3 Message 14.1 Request for practical information on job-seeking activities Is there entitlement under Art. 64 of the Reg. 883/2004? Scanned Document Scanned Document Message 15.1 Total amount which is requested Scanned Document Message 15.1 Number of the single cases included in the reimbursement request Scanned Document Message 18.1 Date on which the payment was due Scanned Document Message 18.1 If yes, interest rate Scanned Document Message 18.1 Message 18.1 Message 18.1 Single case on which interests will be charged Single case on which interests will be charged If yes, total amount of interest charged Amount (basis) on which the interest is charged Scanned Document Scanned Document periodo dal al delle informazioni richieste e riferimenti legislativi certificazione dell' importo di quanto finora pagato ai sensi della legislazione dello stato membro specificazioni delle varie voci di importo totale nominativi delle persone a cui gli importi si riferiscono con specificazioni delle varie voci di importo certificazione della motivazione della data in cui l'importo e' dovuta certificazione motivante il tasso di interesse applicato specifica del tasso di interesse addebitato identificazione delle varie voci componenti l'importo e motivazione legale dell'interesse addebitato Amount of interest for this case Scanned Document certificazione inerente il tasso applicato Message 19.1 Total amount which is reimbursed Scanned Document Message 19.1 specifica delle voci componenti il totale di importo rimborsato Period for which the unemployment benefits were paid From Scanned Document identificazione del numero e della tipologia delle prestazioni a cui il rimborso si riferisce Message 19.2 The date on which the crediting party (institution) received the payment of reimbursements Scanned Document specifiche riguardanti l'accredito 33

318 Liechtenstein Message Object Data element Type of justification Nature Message 1.1 Address of the person concerned in the country in which he/she is registering for benefits Paper copy Employers certificate Message 1.1 Last address of the person concerned in country of former residence Paper copy Employers certificate Message 1.1 Employment Type Employment that is insurance period Paper copy daily allowance Message 1.1 Employment Type Self employment that is Monthly Paper copy insurance period Announcement Message 1.1 Employment Type Employment that is not insurance Certificate of interim Paper copy period earnings Message 1.1 Employment Type Self employment that is not insurance period Paper copy daily allowance Message 1.1 Employment Name and address of employer Paper copy daily allowance Message 1.1 Employment Reason for termination Dismissal by the employer Paper copy Employers certificate Message 1.1 Employment Reason for termination Resignation by the employee Paper copy Employers certificate Message 1.1 Employment Reason for termination Expiry of contract Paper copy Employers certificate Message 1.1 Employment Reason for termination Termination of contract by mutual Paper copy consent Employers certificate Message 1.1 Employment Reason for termination Dismissed for disciplinary reason Paper copy Employers certificate Message 1.1 Employment Reason for termination Other (reason will have to be filled in) Paper copy Employers certificate Message 1.1 Employment Other reason or Reason of termination of Self employment Paper copy Employers certificate Message 1.1 Sickness Type Sickness benefit Paper copy Doctor testimony, Health insurance card, Monthly Announcement Message 1.1 Sickness Name and address of health insurance company Paper copy daily allowance Message 1.1 Maternity Paper copy daily allowance Message 1.1 Maternity Name and address of health insurance company Paper copy daily allowance Message 1.1 Deprivation of liberty Paper copy daily allowance Message 1.1 Education Paper copy daily allowance Message 1.1 Unemployme Name and address of local agency for employment nt benefits or local institution for benefits Paper copy E 301 Message 1.1 Other Type Period of voluntarily continued insurance (name will have to Paper copy daily allowance be filled in under) Message 1.1 Other Type Period treated as a period of insurance Paper copy report Message 1.1 Other Type Activity during period not otherwise covered (nature will have to be filled in under) Paper copy report Message 1.1 Other Name and address of health insurance company Paper copy daily allowance Message 10.1 Message 11.1 Message 12.1 The new last date of the maximum period during which the entitlement to benefits may be retained in accordance with art.64 (a) c) Reg. 883/04 The modified date on which the entitlement to unemployment benefits ended Address of the person concerned in the country in which he/she is registering for benefits Paper copy E 301 Paper copy F 301 Paper copy E 301 Message 12.1 Employment Type Employment that is insurance period Paper copy Employers certificate, Reporting Form Message 12.1 Employment Name and address of employer Paper copy Employers certificate Message 12.1 Employment Reason for termination Dismissal by the employer Paper copy Employers certificate Message 12.1 Employment Reason for termination Resignation by the employee Paper copy Employers certificate Message 12.1 Employment Reason for termination Expiry of contract Paper copy Employers certificate Message 12.1 Employment Reason for termination Termination of contract by mutual Paper copy consent Employers certificate Message 12.1 Employment Reason for termination Dismissed for disciplinary reason Paper copy Employers certificate 34

319 Lithuania Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Paper copy Employment contract Message 1.1 Employment Type Employment that is not insurance period Paper copy Notification from The State Social Insurance Fund Board Message 1.1 Employment Name and address of employer Paper copy Employment contract/standart certificate of employer Message 1.1 Employment Reason for termination Dismissal by the employer Paper copy Employment contract/standart certificate of employer Message 1.1 Employment Reason for termination Resignation by the employee Paper copy Employment contract/standart certificate of employer Message 1.1 Employment Reason for termination Expiry of contract Paper copy Employment contract/standart certificate of employer Message 1.1 Employment Reason for termination Termination of contract by mutual consent Paper copy Employment contract/standart certificate of employer Message 1.1 Employment Reason for termination Dismissed for disciplinary reason Paper copy Employment contract/standart certificate of employer Message 1.1 Employment Reason for termination Other (reason will have to be filled in) Paper copy Employment contract/standart certificate of employer Message 1.1 Sickness Scanned Document Sick note Message 1.1 Sickness Name and address of health insurance company Scanned Document Sick note Message 1.1 Maternity Name and address of health insurance company Scanned Document Maternity note Message 1.1 Deprivation of Notification from The State Social Insurance Scanned Document liberty Fund Board Message 1.1 Education Paper copy Diploma Military or Message 1.1 alternative Military sertificate/notification from The Period From Scanned Document civilian State Social Insurance Fund Board service Message 1.1 Message 1.1 Military or alternative civilian service Unemployme nt benefits Period To Scanned Document Name and address of local agency for employment or local institution for benefits Paper copy Message 1.1 Other Type Presence abroad of a consequence of the applicant accompanying her or his spouse in connection with her or his work abroad Scanned Document Message 1.1 Other Type Period treated as a period of insurance Scanned Document Message 1.1 Message 2.1 Message 2.1 Other Name and address of health insurance company Name and address of employer/place of business Nature of Self employment/employment Paper copy Paper copy Paper copy Military sertificate/notification from The State Social Insurance Fund Board Social sertificate/notificatios fromlithuanian Labour Exchange Message 5.1 Date of registration Paper copy registration certificate Notification from The State Social Insurance Fund Board Notification from The State Social Insurance Fund Board Notification from The State Social Insurance Fund Board Notification from The State Social Insurance Fund Board/standart certificate of employer Notification from The State Social Insurance Fund Board/standart certificate of employer Message 5.1 Name of the unemployment fund in charge in the competent state Paper copy certificate Message 6.1 Date of registration Paper copy Unemployed person's registration card Message 8.1 Message 9.1 Message 10.1 Message 11.1 Is Is the unemployed person still registred with the employment services and complying with organized checking procedures? Date on which the unemployed person returned to the competent state or registered with the competent institution The new last date of the maximum period during which the entitlement to benefits may be retained in accordance with art.64 (a) c) Reg. 883/04 The modified date on which the entitlement to unemployment benefits ended On a monthly basis Paper copy Written notice Paper copy Paper copy Paper copy Message 12.1 Employment Type Employment that is insurance period Paper copy Message 12.1 Employment Type Employment that is not insurance period Paper copy Message 12.1 Employment Name and address of employer Paper copy Written standart notice Written standart notice/certificate Written standart notice/certificate Employment contract/standart certificate of employer Employment contract/standart certificate of employer Employment contract/standart certificate of employer Latvia Message Object Subobject Data element Type of justification Nature Message 15.1 Total amount which is requested Paper copy lēmums par pabalsta piešķiršanu Message 15.1 Number of the single cases included in the reimbursement request Paper copy lēmums par pabalsta piešķiršanu Message 19.1 Total amount which is reimbursed Paper copy maksājuma uzdevums 35

320 Luxembourg Message Object Subobject Data element Type of justification Nature Message 10.1 The new last date of the maximum period during which the entitlement to benefits may be retained in accordance with art.64 (a) c) Reg. 883/04 Paper copy Malta Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Scanned Document FS3 Form Message 1.1 Employment Type Self employment that is insurance period Scanned Document Receipts of Contribution Payments for the last year preceeding the date of claim Message 12.1 Employment Type Employment that is insurance period Scanned Document FS3 Form Message 12.1 Employment Type Self employment that is insurance period Scanned Document Receipts of Contribution Payments for the last year preceeding the Date of Claim Netherlands Message Object Subobject Data element Type of justification Nature Message 6.1 Date of registration Scanned Document Message 8.1 Is Is the unemployed person still registred with the employment services and complying with organized checking procedures? On a monthly basis Scanned Document national UB-form Message 11.1 The modified date on which the entitlement to unemployment benefits ended Scanned Document letter of decision to the jobseeker Message 15.1 Total amount which is requested Scanned Document Message 15.1 Number of the single cases included in the reimbursement Scanned Document request Message 15.1 Single case Date on which the entitlement to UB begins Scanned Document Message 15.1 Single case Date of last payment, at the same time key date for defining the exchange rate for the Scanned Document reimbursement Message 15.1 Single case Amount of the payment for the requested period Scanned Document Message 18.1 Date on which the payment was due Scanned Document Message 18.1 If yes, interest rate Scanned Document Message 18.1 If yes, total amount of interest charged Scanned Document Message 18.1 Message 18.1 Single case on which interests will be charged Single case on which interests will be charged Amount (basis) on which the interest is charged Amount of interest for this case Scanned Document Scanned Document Message 19.1 Total amount which is reimbursed Scanned Document 36

321 Norway Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 1.1 Employment Name and address of employer Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 1.1 Employment Reason for termination Dismissal by the employer Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 1.1 Employment Reason for termination Resignation by the employee Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 1.1 Employment Reason for termination Expiry of contract Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 1.1 Employment Reason for termination Termination of contract by mutual consent Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 1.1 Employment Reason for termination Dismissed for disciplinary reason Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 1.1 Employment Reason for termination Other (reason will have to be filled in) Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 1.1 Military or alternative civilian Period From Scanned Document Vernepliktsbok service Message 1.1 Military or alternative civilian Period To Scanned Document Vernepliktsbok service Message 5.1 Date of registration Scanned Document E303/2 Message 5.1 Name of the unemployment fund in charge in the competent state Scanned Document E303/2 Message 6.1 Date of registration Scanned Document E 303/2 Message 7.1 Starting date of circumstances likely to effect the entitlement to From Scanned Document Brev/Notat benefits Message 8.1 Is Is the unemployed person still registred with the employment services and complying with On a monthly basis Scanned Document Notat organized checking procedures? Message 9.1 Date on which the unemployed person returned to the competent state or registered with the Scanned Document Notat competent institution Message 10.1 The new last date of the maximum period during which the entitlement to benefits may be Scanned Document E303 retained in accordance with art.64 (a) c) Reg. 883/04 Message 12.1 Employment Type Employment that is insurance period Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 12.1 Employment Name and address of employer Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 12.1 Employment Reason for termination Dismissal by the employer Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 12.1 Employment Reason for termination Resignation by the employee Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 12.1 Employment Reason for termination Expiry of contract Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 12.1 Employment Reason for termination Termination of contract by mutual consent Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 12.1 Employment Reason for termination Dismissed for disciplinary reason Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 12.1 Employment Reason for termination Other (reason will have to be filled in) Scanned Document NAV , Bekreftelse på ansettelsesforhold Message 12.1 Military or alternative civilian Period From Scanned Document Vernepliktsbok service Message 12.1 Military or alternative civilian Period To Scanned Document Vernepliktsbok service Message 15.1 Single case Scanned Document E 303/4 37

322 Poland Message Object Subobject Data element Type of justification Nature Certificate of employment - "Swiadectwo Message 1.1 Employment Type Employment that is insurance period Scanned Document pracy" or certificate from social insurance company - ZUS Message 1.1 Employment Self employment that is insurance period Scanned Document Certificate from social insurance company - ZUS or KRUS Message 1.1 Employment Employment that is not insurance period Scanned Document Certificate of employment - "Swiadectwo pracy" or certificate from social insurance company - ZUS Message 1.1 Employment Self employment that is not insurance period Scanned Document Certificate from social insurance company - ZUS or KRUS Message 1.1 Employment Reason for termination Dismissal by the employer Scanned Document "Swiadectwo pracy" Message 1.1 Employment Resignation by the employee Scanned Document "Swiadectwo pracy" Message 1.1 Employment Expiry of contract Scanned Document "Swiadectwo pracy" Message 1.1 Employment Termination of contract by mutual consent Scanned Document "Swiadectwo pracy" Message 1.1 Employment Dismissed for disciplinary reason Scanned Document "Swiadectwo pracy" Message 1.1 Employment In case of self employment not Certificate from social insurance company - treated as insurance period, Scanned Document ZUS or KRUS earnings Message 1.1 Sickness Period From Scanned Document Certificate from social insurance company - ZUS or KRUS Message 1.1 Maternity Period From Scanned Document Certificate of employment - "Swiadectwo pracy" or certificate from social insurance company - ZUS or KRUS Message 1.1 Maternity To Scanned Document Message 1.1 Message 1.1 Message 1.1 Deprivation of liberty Military or alternative civilian service Military or alternative civilian service Period From Scanned Document Period From Scanned Document To Scanned Document Certificate from social insurance company - ZUS or KRUS - or relvant certificate from prison service copy of relevant pages of military service document - "ksiazeczka wojskowa' Message 1.1 Other Period treated as a period of insurance Scanned Document copy of a relevant document certifiing periods treated as periods of insurance other than mentioned above Message 1.1 Other Activity during period not otherwise covered (nature will have to be filled in under) Scanned Document Message 12.1 Employment Type Employment that is insurance period Scanned Document Certificate of employment - "Swiadectwo pracy" or certificate from social insurance company - ZUS Message 12.1 Employment Self employment that is insurance period Scanned Document Certificate from social insurance company - ZUS or KRUS Message 12.1 Employment Employment that is not insurance period Scanned Document Certificate of employment - "Swiadectwo pracy" or certificate from social insurance company - ZUS Message 12.1 Employment Self employment that is not insurance period Scanned Document Certificate from social insurance company - ZUS or KRUS Message 12.1 Employment Reason for termination Dismissal by the employer Scanned Document "Swiadectwo pracy" Message 12.1 Employment Resignation by the employee Scanned Document "Swiadectwo pracy" Message 12.1 Employment Expiry of contract Scanned Document "Swiadectwo pracy" Message 12.1 Employment Termination of contract by mutual consent Scanned Document "Swiadectwo pracy" Message 12.1 Employment Dismissed for disciplinary reason Scanned Document "Swiadectwo pracy" Message 12.1 Employment In case of self employment not treated as insurance period, earnings Scanned Document Message 12.1 Sickness Period From Scanned Document Certificate from social insurance company - ZUS or KRUS Certificate from social insurance company - ZUS or KRUS Message 12.1 Maternity Period From Scanned Document Certificate of employment - "Swiadectwo pracy" or certificate from social insurance company - ZUS or KRUS Message 12.1 Maternity To Scanned Document Message 12.1 Certificate from social insurance company - Deprivation of Period From Scanned Document ZUS or KRUS - or relvant certificate from liberty prison service Message 12.1 Message 12.1 Military or alternative civilian service Military or alternative civilian service Period From Scanned Document To Scanned Document Message 12.1 Other Period treated as a period of insurance Scanned Document copy of relevant pages of military service document - "ksiazeczka wojskowa' copy of a relevant document certifiing periods treated as periods of insurance other than mentioned above 38

323 Rumania Message Object Subobject Data element Type of justification Nature for employment periods preceeding 1st Message 1.1 Employment Type Employment that is insurance period Scanned Document March 2002: workbook, or certificate from the employer Message 1.1 Employment Type Self employment that is insurance period Scanned Document unemployment insurance contract Message 1.1 Employment Type Employment that is not insurance period Scanned Document workbook or labour contract, certificate issued by the employer Message 10.1 The new last date of the maximum period during which the entitlement to benefits may be Scanned Document letter from the competent institution retained in accordance with art.64 (a) c) Reg. 883/04 Message 11.1 The modified date on which the entitlement to unemployment Scanned Document letter from the competent institution benefits ended Message 12.1 Employment Type Employment that is insurance period Scanned Document for employment periods preceding 1st March 2002: workbook, labour contract or certificate from the employer Message 12.1 Employment Type Self employment that is insurance period Scanned Document unemployment insurance contract Message 12.1 Employment Type Employment that is not insurance period Scanned Document workbook, labour contract or certificate from the employer Message 15.1 Single case Date on which the entitlement to documents upon which was made the Original UB begins payment of UB Message 15.1 Single case End of the period for which the documents upon which was made the reimbursement is requested Original payment of UB (maximum 3 or 5 month) Message 15.1 Message 15.1 Message 18.1 Single case Single case Date of last payment, at the same time key date for defining the exchange rate for the reimbursement Amount of the payment for the requested period Date on which the payment was due Original Original Paper copy documents upon which was made the payment of UB documents upon which was made the payment of UB reimbursement claim Slovakia Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Scanned Document zápočtový list, pracovná zmluva Message 1.1 Employment Type Employment that is not insurance period Scanned Document zápočtový list, pracovná zmluva Message 1.1 Employment Name and address of employer Scanned Document zápočtový list, pracovná zmluva Message 1.1 Other Type Period of voluntarily continued insurance (name Scanned Document will have to be filled in under) vyhlásenie poistenca Message 12.1 Employment Type Employment that is insurance period Scanned Document zápočtový list, pracovná zmluva Message 12.1 Employment Type Employment that is not insurance period Scanned Document zápočtový list, pracovná zmluva Message 12.1 Employment Name and address of employer Scanned Document zápočtový list, pracovná zmluva Slovenia Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Paper copy the copy of employment booklet or contract Message 1.1 Employment Type Self employment that is insurance period Paper copy the copy of employment booklet Message 1.1 Employment Reason for termination Dismissal by the employer Paper copy resolution, contract Message 1.1 Employment Reason for termination Resignation by the employee Paper copy resolution Message 1.1 Employment Reason for termination Expiry of contract Paper copy contract Message 1.1 Employment Reason for termination Termination of contract by mutual consent Paper copy consensual derogation Message 1.1 Employment Reason for termination Dismissed for disciplinary reason Paper copy resolution Message 1.1 Employment Reason for termination Other (reason will have to be filled in) Paper copy Message 1.1 Employment Other reason or Reason of termination of Self employment Paper copy Message 1.1 Employment In case of self employment not treated as insurance period, earnings Paper copy Message 5.1 Date of registration IT Message 6.1 Date of registration Message 6.1 Address of the unemployed person in the country in which he / she is seeking for work 39

324 Spain Message Object Subobject Data element Type of justification Nature Message 15.1 Single case Name and address of the Institution certifying insurrance records Message 15.1 Single case Date on which the entitlement to UB begins Message 15.1 Single case End of the period for which the reimbursement is requested (maximum 3 or 5 month) Message 15.1 Single case Date of last payment, at the same time key date for defining the exchange rate for the reimbursement Message 15.1 Single case Amount of the payment for the requested period Sweden Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Reason for termination Termination of contract by mutual consent Scanned Document Message 1.1 Employment Reason for termination Dismissed for disciplinary reason Scanned Document Message 1.1 Employment Reason for termination Other (reason will have to be filled in) Scanned Document Message 1.1 Employment Other reason or Reason of termination of Self employment Scanned Document 40

325 Switzerland Message Object Subobject Data element Type of justification Nature Message 1.1 Address of the person concerned in the country in which he/she is registering for benefits Paper copy attestation domicile Message 1.1 Last address of the person concerned in country of former Paper copy attestation officielle residence Message 1.1 Employment Type Employment that is insurance period Paper copy attestation employeur Message 1.1 Employment Type Self employment that is insurance period Paper copy attestation sécurité sociale Message 1.1 Employment Type Employment that is not insurance period Paper copy attestation officielle Message 1.1 Employment Type Self employment that is not insurance period Paper copy attestation sécurité sociale Message 1.1 Employment Name and address of employer Paper copy attestation employeur Message 1.1 Employment Reason for termination Dismissal by the employer Paper copy lettre de résiliation Message 1.1 Employment Reason for termination Resignation by the employee Paper copy lettre de résiliation Message 1.1 Employment Reason for termination Expiry of contract Paper copy contrat de travail Message 1.1 Employment Reason for termination Termination of contract by mutual consent Paper copy lettre de résiliation Message 1.1 Employment Reason for termination Dismissed for disciplinary reason Paper copy lettre de résiliation Message 1.1 Employment Reason for termination Other (reason will have to be filled in) Paper copy lettre de résiliation Message 1.1 Employment Other reason or Reason of termination of Self employment Paper copy extrait registre commerce Message 1.1 Employment In case of self employment not treated as insurance period, Paper copy déclaration individuelle number of hours Message 1.1 Sickness Paper copy attestation d'assurance Message 1.1 Sickness Name and address of health insurance company Paper copy attestation d'assurance Message 1.1 Maternity Paper copy déclaration individuelle Message 1.1 Maternity Name and address of health insurance company Paper copy attestation assurance Message 1.1 Deprivation of liberty Paper copy attestation officielle + attestation employeur Message 1.1 Education Paper copy attestation officielle Message 1.1 Military or alternative civilian Period From Paper copy attestation officielle service Message 1.1 Military or alternative civilian service Period To Paper copy attestation officielle Message 1.1 Unemployme nt benefits Name and address of local agency for employment or local institution for benefits Paper copy attestation officielle Message 1.1 Other Type Presence abroad of a consequence of the applicant accompanying her or his spouse in connection with her or his work abroad Paper copy attestation officielle Message 1.1 Other Type Period of voluntarily continued insurance (name Paper copy will have to be filled in under) attestation officielle Message 1.1 Other Type Period treated as a period of insurance Paper copy attestation officielle Message 1.1 Other Type Activity during period not otherwise covered (nature will have to be filled in under) Paper copy attestation officielle Message 1.1 Other Name and address of health insurance company Paper copy attestation officielle Message 2.1 Last address of the person concerned in country of former Paper copy attestation domicile residence Message 2.1 Name and address of employer/place of business Paper copy attestation employeur Message 2.1 Nature of Self employment/employment Paper copy attestation employeur Message 5.1 Date of registration Paper copy attestation officielle Message 5.1 Address of the unemployed person in the country in which he / she is seeking for work Paper copy attestation officielle Message 5.1 Last address of the unemployed person in the competent state Paper copy attestation officielle Message 5.1 Name of the unemployment fund in charge in the competent state Paper copy attestation officielle Message 6.1 Date of registration Paper copy attestation officielle Message 6.1 Address of the unemployed person in the country in which he / she is seeking for work Paper copy attestation officielle UK Message Object Subobject Data element Type of justification Nature Message 1.1 Employment Type Employment that is insurance period Scanned Document Payslip Message 1.1 Employment Self employment that is insurance period Scanned Document Payslip Message 1.1 Employment Employment that is not insurance period Scanned Document Payslip Message 1.1 Employment Self employment that is not insurance period Scanned Document Payslip Message 12.1 Employment Type Employment that is insurance period Scanned Document Payslip Message 12.1 Employment Self employment that is insurance period Scanned Document Payslip Message 12.1 Employment Employment that is not insurance period Scanned Document Payslip Message 12.1 Employment Self employment that is not insurance period Scanned Document Payslip 41

326 Family Benefits The business and data flows suggested by the ad-hoc group are below. The group has identified the common data elements for family benefits in the Member States. It has completed the data it identified based on the comments received as answers to the questionnaire it prepared and sent to countries. With regard to the data flows the group suggests a two-fold approach, i.e. (1) data which always need to be exchanged and (2) additional data which only need to be exchanged if necessary. With regard to such additional data, it should not be linked to a certain Member State since the establishing of data sheets per Member State would be too cumbersome due to the large variety of family benefits. The idea is that the clerk making the request to another Member State could click which information it requires in this particular situation. This possibility to choose the relevant data should be possible for both (1 and 2) types of data. The SEDs used in the data flows should be as flexible as possible. The group feels that family benefits are a special group of benefits in the regulations in this respect. The family benefits in the Member States are various and the data elements required for providing these benefits are significant in number. It is also typical for family benefits that there can be different data requirements for different members of the family, this is especially so in relation to families with children with different parents. The relevant data identified by the group is described in general terms. This means that when the final SEDs are going to be produced the exact wording and placing of the data elements needs to be phrased in further details. As the composition of a SED is not yet clear it was not possible for the group to think of all the possibilities the structure of the SED will give. The data for family benefit flows are specified in the flow annexe (annexe T1).

327 "Legislation applicable"- Data Needed First layer: Essential common elements for all messages that are exchanged on the basis of Title II of Reg. (EC) Nr. 883/2004 Common data for all articles The person concerned 1 ; The employer concerned 2 ; The starting date and time period during which activities as an employed or self-employed person are going to be pursued; The legislation applicable to the activities; The article of the Regulation on which basis the message is exchanged; The institution that has sent the message. Data are sent: From: the Member State in which the person concerned pursues or pursued an activity as an employed or a self-employed person; To: the Member State in which the person is going to pursue or is pursuing an activity as an employed or a self-employed person. Second layer: additional data for messages that are exchanged on the basis of Title II of Reg. (EC) Nr. 883/2004 Additional messages: Art Reg (EC) Nr. 883/2004, art Implementing Reg. The flag of the Member State which the vessel is flying; The place of the registered office of the undertaking which, or the place of business of the person who employs and remunerates the person concerned; The place of residence of the person concerned. From: the Member State whose flag the vessel is flying; To: the Member State where the employers registered office, or the place of business of the person remunerating the person concerned, is located. Art Reg. (EC) Nr. 883/2004, art. 14.1, 14.2 and 15.1 Implementing Reg. The date on which the person became subject to the legislation of the Member State where the undertaking which employs him is established; The actual nature of the activities of the undertaking that are pursued in the sending Member State and in the receiving Member State; 1 This identification of the natural person is investigated by the Ad hoc group on Identification 2 The mode of identification of the employer has to be decided.

328 The actual place where the person pursues its activities during the period of posting. From: the sending Member State; To: the receiving Member State. Art Reg. (EC) Nr. 883/2004, art and 14.4 Implementing Reg. Since when the self-employed person pursues his or her activities in the Member State in which he or she is established; The actual nature of the activity pursued in the sending Member State and in the receiving Member State; The maintenance of requisite means in the Member State where the self-employed person is established; The actual place where the activities are pursued during the period of posting. From: the sending Member state; To: the receiving Member state. Third layer: data to be kept available by the Member States and that are sent on request Art Reg. (EC) Nr. 883/2004 The kind of the cash benefits that are paid; The date until which the cash benefit were paid; Whether the cash benefits are still being paid. From: the Member State in which the person concerned previously pursued an activity as an employed or a self-employed person; To: the (new) Member State of residence. Art a Reg. (EC) Nr. 883/2004 The date on which the legislation of another Member State becomes applicable. From: the Member state in which the person concerned pursues or pursued an activity as an employed or a self-employed person; To: the Member State in which the person is going to pursue or is pursuing an activity as an employed or a self-employed person. Art Reg. (EC) Nr. 883/2004, art. 14.5, 14.6.a, 14.7 and 17 Implementing Reg. The nature of the activities pursued; The duration of the activities; The place where activities are pursued; The working time; The remuneration; From: the Member State of residence; To: the to the Member state(s) in which the person concerned pursues an activity as an employed person.

329 Art Reg. (EC) Nr. 883/2004, art. 14.6, 14.6a, 14.7, 14.8 and 17 Implementing Reg. The (habitual) nature of the activities pursued; The duration of the activities; The place where the activities are pursued; The working time; The turnover/income; The number of services rendered in a Member State. From: the Member State of residence; To: the Member State(s) in which the person concerned pursues an activity as a self-employed person.

330 Identification of persons The expert group on identification of persons aimed to establish the minimum common dataset that needs to be exchanged to identify individual claimants within flows. The purpose is for an institution in country A to allow the receiving institution in country B to find records about the claimant in their databases. This, with a view for country B to assess the social security rights of the claimant. Hence, the dataset below needs to be exchanged in each claim and will be part of each SED message. SED messages defined by other expert groups, concerning the data to be exchanged for specific claims, make reference to and include the dataset below. The expert group found that the identification when the receiving institution's PIN is known is rather different from when the PIN is unknown and therefore have identified two datasets to cover the two separate cases: Minimum Data Set Where a Personal Identification Number is present: Where a Personal Identification Number (e.g. a National Registration Number or Sectoral Reference Number) is present the minimum data set* is: Personal Identification Number; Surname/Family Name; Forename(s); Date of Birth; Sex; Name at Birth (Surname/Family Name and Forename(s). Minimum Data set where a Personal Reference Number is not present Where a Personal Identification Number (e.g. a National Registration Number or Sectoral Reference Number) is not present the minimum data set is: Surname/Family Name; Forename(s); Date of Birth; Sex; Place of Birth; Surname/Family Name at Birth; Father Surname/Family Name at Birth (if different); Mother Surname/Family Name at Birth (if different); Forename(s) of Father; Forename(s) of Mother; Data Definitions During analysis we have concluded that the definition for a number of items were common. The following table identifies where this is the case and indicates which items do not have separate definitions. Data item Definition template included below? 01-Personal Identification Number Yes 02-Surname/Family Name Yes 03-Other Name(s) Yes

331 04- Date of Birth Yes 05-Sex Yes 06-Place of Birth Yes 07-Surname/Family Name at birth Yes 08-Mother s Surname/Family name at birth No definition specified in data item 02 Surname/Family name 09-Surname/Family name of Mother No definition specified in data item 02 Surname/Family name 10- Other Name(s) of Mother No definition specified in data item 03 Other Name(s) 11- Surname/Family name of Father No definition specified in data item 02 Surname/Family name 12- Other Name(s) of Father No definition specified in data item 03 Other Name(s) NB. The issue of how to accommodate characters particular to Greek/other alphabet remains to be resolved. PERSONAL IDENTIFICATION NUMBER (PIN) Note, the PIN is still being discussed as there could be different PINs for different sectors. In addition, the PIN should be supplemented with a country code. The contractor is to contact the Commission with a view to discussing how the PIN should be represented. REF NUMBER: 001 STATUS: Baselined VERSION NUMBER: 1 VERSION DATE: 12/06/07 OWNER: CA.SS.TM Task Force on Electronic Data Exchange DEFINITION: A UNIQUE PERSONAL IDENTIFICATION NUMBER ISSUED BY A STATE OR ORGANISATION MAXIMUM SIZE 16 INTERFACE FORMAT Alpha numerical VALIDATION Minimum of 9 maximum of 16 alpha numerical NOTES Where ever possible the number entered should be a number given to an individual under a National Registration scheme. Where no National Registration number is available, a sectoral (i.e. Social security, Heath registration number) should be entered REFERENCES TESS Build 6 co-ordinated glossary of terms ICAO Specifications

332 UN CEFACT Definitions E- gov interoperability framework v6 SURNAME/ FAMILY NAME REF NUMBER: 002 STATUS: Baselined VERSION NUMBER: 1 VERSION DATE: 12/06/07 OWNER CA.SS.TM Task Force on Electronic Data Exchange DEFINITION: THE PART OF A PERSON S NAME WHICH IS USED TO DESCRIBE FAMILY, CLAN, TRIBAL GROUP or MARITAL ASSOCIATION. MAXIMUM SIZE Recommended 70 characters 1 INTERFACE FORMAT Alpha numerical VALIDATION Alpha numerical NOTES REFERENCES From ICAO definition: Where the issuing state or organisation determines that the holders name cannot be divided into the required 2 parts as defined below, the full name of the holder shall be defined as the primary identifier. Primary identifier: Predominant component(s) of the name of the holder as described below. In cases where the predominant components of the name of the holder (e.g. where this consists of composite names) cannot be shown in full or in the same order, owing to space limitations of field(s) 06 and/or 07 or national practise, the most important component(s) (as determined by the State or organisation of the primary identifier) shall be inserted TESS Build 6 co-ordinated glossary of terms ICAO Specifications UN CEFACT Definitions E- gov interoperability framework v6 1 EHIC data field is up to 40 characters in length (Ref: Decision No. 190 of 18 June 2003 concerning the technical specifications of the European Health Insurance Card)

333 OTHER NAME(S) REF NUMBER: 003 STATUS: Baselined VERSION NUMBER: 1 VERSION DATE: 12/06/07 OWNER CA.SS.TM Task Force on Electronic Data Exchange DEFINITION: THE NAME(S) THAT ACCOMPANY AN INDIVIDUALS SURNAME/FAMILY NAME. MAXIMUM SIZE Recommended 70 characters 2 INTERFACE FORMAT Alpha numerical VALIDATION Maximum of 70 alpha numerical NOTES From ICAO definition: Where the issuing state or organisation determines that the holders name cannot be divided into the required 2 parts as defined below, the full name of the holder shall be defined as the primary identifier. REFERENCES Secondary Identifier: secondary component(s) of the name of the holder as described below. The most important component(s) (as determined by the State or organisation) of the secondary identifier of the holder shall be inserted in full up to the maximum dimensions of the field frame. Other components, where necessary, may be represented by initials. Where the holder s name has only predominant component(s) this data field shall be left blank. A State may optionally utilize the whole zone comprising of fields 06 & 07 as a single field. In such a case, the primary identifier shall be placed first, followed by a comma and a space, followed by the secondary identifier. TESS Build 6 co-ordinated glossary of terms ICAO Specifications UN CEFACT Definitions E- gov interoperability framework v6 2 EHIC data field is up to 35 characters in length (Ref: Decision No. 190 of 18 June 2003 concerning the technical specifications of the European Health Insurance Card)

334 DATE OF BIRTH REF NUMBER: 004 STATUS: Baselined VERSION NUMBER: 1 VERSION DATE: 12/06/07 OWNER CA.SS.TM Task Force on Electronic Data Exchange DEFINITION: THE DATE ON WHICH A PERSON IS BORN OR IS OFFICIALLY DEEMED TO HAVE BEEN BORN. MAXIMUM SIZE 8 INTERFACE FORMAT Numerical - a day & month should be shown by 2 digits and a year by 4 digits. VALIDATION Numerical - a day & month should be shown by 2 digits and a year by 4 digits NOTES REFERENCES TESS Build 6 co-ordinated glossary of terms ICAO Specifications UN CEFACT Definitions E- gov interoperability framework v6 SEX REF NUMBER: 005 STATUS: Baselined VERSION NUMBER: 1 VERSION DATE: 12/06/07 OWNER CA.SS.TM Task Force on Electronic Data Exchange DEFINITION: A PERSONS GENDER AS RECORDED ON THE BIRTH CERTIFICATE OR OTHER OFFICIAL DOCUMENT. MAXIMUM SIZE 1 INTERFACE FORMAT Alpha M or F VALIDATION M or F NOTES

335 REFERENCES TESS Build 6 co-ordinated glossary of terms ICAO Specifications UN CEFACT Definitions E- gov interoperability framework v6 PLACE OF BIRTH REF NUMBER: 006 STATUS: Baselined VERSION NUMBER: 1 VERSION DATE: 12/06/07 OWNER CA.SS.TM Task Force on Electronic Data Exchange DEFINITION: STATE PLACE OF BIRTH NOTE GENERALLY THE REGISTRATION DISTRICT IN WHICH THE BIRTH WAS RECORDED AND, WHERE APPROPRIATE, THE LARGER GEOGRAPHICAL ENTITY IN WHICH THIS REGISTRATION DISTRICT IS LOCATED I.E. CITY, COUNTY, TOWN, COUNTRY. MAXIMUM SIZE Recommended 35 characters for town, 35 characters for region and 3 character ISO code for country INTERFACE FORMAT Alpha numerical it is recommended that town, region and country are included as separate data fields VALIDATION Alpha numerical NOTES From ICAO definition: A translation of the name into 1 or more languages, one of which should be English, French or Spanish should be given when translated name is more familiar to the international community. At the discretion of the Issuing State, the Town or suburb of the birth may be used. When the MRP is issued to a person whose place of birth was outside the State issuing the document and it is desired, that State or territory of birth be shown, the three-lettered code appearing in Appendix 7 shall be used. REFERENCES TESS Build 6 co-ordinated glossary of terms ICAO Specifications UN CEFACT Definitions E- gov interoperability framework v6

336 SURNAME / FAMILY NAME AT BIRTH REF NUMBER: 007 STATUS: Baselined VERSION NUMBER: 1 VERSION DATE: 12/06/07 OWNER CA.SS.TM Task Force on Electronic Data Exchange DEFINITION: THE PART OF A PERSON S NAME WHICH IS USED TO DENOTE FAMILY, CLAN, TRIBAL GROUP AS REGISTERED AT BIRTH OR RECORDED ON OTHER OFFICIAL DOCUMENTS THAT SUPERSEDE THE BIRTH CERTIFICATE. MAXIMUM SIZE 70 INTERFACE FORMAT Alpha numerical VALIDATION Alpha numerical NOTES From ICAO definition: Where the issuing state or organisation determines that the holders name cannot be divided into the required 2 parts as defined below, the full name of the holder shall be defined as the Primary identifier. Primary Identifier: Predominant component(s) of the name of the holder as described below. In cases where the predominant components of the name of the holder (e.g. where this consists of composite names) cannot be shown in full or in the same order, owing to space limitations of field(s) 06 and/or 07 or national practise, the most important component(s) (as determined by the State or organisation of the primary identifier shall be inserted REFERENCES From TESS definition the maiden name of a woman is equivalent to the surname / family name at birth TESS Build 6 co-ordinated glossary of terms ICAO Specifications UN CEFACT Definitions E- gov interoperability framework v6

337 EUROPEAN COMMISSION DIRECTORATE-GENERAL Employment, Social Affairs and Equal Opportunities Social Protection and Integration Coordination of Social Security Schemes, Free Movement of Workers Open Call for Tender VT/2008/019 Informatics services and products in the context of the EESSI (Electronic Exchange of Social Security Information) project Technical Specifications Annex T 3 Social security indicative exchange metrics Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 1 of 12

338 Table of Content 1. SOCIAL SECURITY INDICATIVE METRICS SOURCE ASSUMPTIONS Number of electronic documents Size of SED information content SSED XML encoding size factor SSED file size Results and acknowledgements File packing factor File envelope overhead Web services overhead EESSI protocols overhead DATA TRAFFIC ESTIMATIONS...8 Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 2 of 12

339 1. SOCIAL SECURITY INDICATIVE METRICS 1.1. SOURCE The following text gives an indication of the intensity of the exchanges that are to be supported by the EESSI system to be developed. This estimate is taken from a study aiming to establish the bandwidth requirements of the EESSI international network, the coordination node and the access points. The starting point of the analysis is an assumption on the annual total number of SEDs exchanged and their size. It is stressed that the resulting estimations are purely indicative and have a wide margin of uncertainty. In addition, these estimates are based on assumptions as to the formats and behaviour that will affect the message sizes. Any changes in these factors, for instance if senders pack less, will have an impact on the real flow intensity once the EESSI system is running ASSUMPTIONS To estimate the annual volume of the data traffic in the EESSI international domain, several assumptions have to be made. This section discusses those assumptions NUMBER OF ELECTRONIC DOCUMENTS In the deliverable FS-01 Description of the current exchanges we presented an estimation of the SED exchanged annually in the EU 25. Table 1 gives those estimations. Table 1: Annual volume of Exxx forms exchanged in EU 25 Volume of information Sector exchange (in E-forms 1 ) Accuracy Pension 2,195,000 Moderate, ± 20% Health 3,535,000 Moderate, ± 20% Unemployment 1,000,000 Very low Family benefits 1,000,000 Very low Posting 800,000 High, ± 5% Total 8,530,000 Moderate, ± 30% Setting aside any considerations about the accuracy of the above estimations, the annual volume of SED in EESSI will, of course, be greater than the figures given in Table 1 for two primary reasons. First, there will be more countries involved in the EESSI data exchange, since the newest EU countries (Bulgaria and Romania), as well as the EFTA countries and Switzerland will participate. Second, there will be additional data traffic for the healthcare sector, as there may be on-line (i.e. on-the-spot) checks for entitlement to free healthcare when a citizen presents 1 E-forms are a series of forms labelled E101, E204, E601 etc., that are currently exchanged with a view to implementing the current regulation on social security across countries in the EU. Some are exchanged by letter, some fax and others via a plethora of piece-meal electronic means. Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 3 of 12

340 himself, and possibly their EHIC 2, to a provider of a healthcare in a Member State in which they are not resident. In other words, healthcare data exchange will not concern only the electronic exchanges of the E125/E127 but also the data exchange of EHIC. Table 2 gives our assumptions of the annual volume of SED exchanged in EESSI for the purposes of the date traffic analysis. For the purposes of the data traffic analysis we have made the following two key assumptions. The total number of SEDs exchanged in EESSI is 50% more than that of EU 25 There will be 2,500,000 on-line checks to verify entitlement to free healthcare to another Member State Table 2 gives the resulting the annual volume of SED exchanged in EESSI. Table 2: Scenario for the annual volume of SED exchanged in EESSI Sector Annual volume of SED exchanged Pensions 3,300,000 Healthcare 5,300,000 Check for entitlement to free healthcare 2,500,000 Family benefits 1,500,000 Unemployment 1,500,000 Postings 1,200,000 Total 15,300,000 Please note that the total above is an estimate concerning the six areas mentioned in the table (covering five sectors). EESSI will also manage the exchanges of additional sectors, whose complete list is in the Administrative Specifications, section However, the main sectors are listed and counted above and it is expected that the outstanding sectors do not add an important number of messages SIZE OF SED INFORMATION CONTENT We consider as the content of an SED the character strings conveying the business information of the document. For instance, if an SED is prepared by filling-in a Web form, then its information content are the character strings typed. In the Build-5 pilot project, the E125 and E127 forms (valid from 1st January 2007) have been encoded in fixed-size record format (MTF format). Table 3 gives details of the record properties. Table 3: Properties of the E125 and E127 Build-5 fixed-size records E form Number of fields Total size of all Average field size fields (characters) (characters) E E The EHIC, or European Health-Insurance Card, is a non-electronic document that attests that the holder is insured by a country participating in the scheme (i.e. EU plus non-eu EEA and Switzerland). See Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 4 of 12

341 A quick analysis of the E2xx forms, and a conservative estimate (i.e. one towards overestimation) yields that they contain about 200 fields each. A notable case where this 200- field assumption does not apply is the E213 form. Assuming an average field size of 20 characters, it follows the E2xx forms have a content of about 4,000 characters. An analysis of the E205 form indicates that it takes about 1,600 characters. Based on the above, we have assumed that the size of the SED information content is 2,500 characters or 2.5 KB. In arriving to a size in KB from the number of characters, we have considered that that information content of SED is encoded in UTF-8 and that nearly all characters will be Latin SSED XML ENCODING SIZE FACTOR It is well known that the encoding of data in XML can take over several times the number of bytes of the actual data. Careful design of the XML schema with attention to the resulting file size can have a significant impact on the XML file size. We have assumed that the XML encoding size factor will be eight (8), which means that XML encoding of the SED information content will result in an XML file whose size is 8 times larger than the size of the latter content. This sizing factor does not account for the additional increase of the file size when security features are applied to the file (e.g. digital signatures etc.) SSED FILE SIZE XML-encoded SED will be compressed to conserve bandwidth. We have assumed a XML-file compression factor of four (4), which means that the compressed XML file will be four times smaller than the uncompressed one. Table 4 gives an analysis our assumptions of the size of the SED. The size of the compressed XML-encoded SED is calculated by the formula: Size of compressed XML file = Size of information content * XML-encoding factor / Compression factor Table 4: Size of files analysis Sector Size of information content (characters/kb) XMLencoding factor Compression factor Pensions 2,500/ Healthcare 2,500/ Check for entitlement to free healthcare 1,000/1 8 4 Compressed XML file size (KB) Family benefits 2,500/ Unemployment 2,500/ Postings 1,000/ Note, this is only specified for size estimation purposes; in building the EESSI system, the contractor has to make provisions at least for Greek and Bulgarian characters. Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 5 of 12

342 RESULTS AND ACKNOWLEDGEMENTS When a SED is received by an access point, certain operations take place including checking the validity and the conformity of the incoming SED and subsequently routing of the SED to the Competent Institution. In the current implementation of electronic exchanges in TESS, the receiving access point sends to the sender access point an acknowledgement that an SED was received. The same principle will likely apply to EESSI, that is, SED will be acknowledged. Regarding the checks for entitlement to free healthcare and postings, we have assumed that the sender access point issues a query and the receiving access point replies in a synchronous manner (i.e. the rely is provided on-line). Therefore there is a single reply, for which we have assumed that its size is 2 KB and is sent back uncompressed. For the pensions, healthcare, family benefits and unemployment sectors, we have assumed that there are two acknowledgments which the receiving access point sends back to the sender access point; one that that the SED was received and validated and a second one that that the SED was routed to Competent Institution. Assuming that both acknowledgements have information content whose size is 0.5 KB (i.e. 500 characters), an XML-encoding factor of eight (8) and a compression factor of four (4), it follows that the size of the acknowledgement file is 0.5 KB * 8 / 4 = 1 KB. Table 5 gives our assumptions for the file size of the results and acknowledgements. Table 5: Results and acknowledgement file size Sector Pensions Healthcare Check for entitlement to free healthcare Family benefits Unemployment Postings Results and acknowledgement 1. Acknowledgement that SED was received and validated 2. Acknowledgement that SED was routed to Competent Institution 1. Acknowledgement that SED was received and validated 2. Acknowledgement that SED was routed to Competent Institution Result, individual is entitled to free healthcare or not 1. Acknowledgement that SED was received and validated 2. Acknowledgement that SED was routed to Competent Institution 1. Acknowledgement that SED was received and validated 2. Acknowledgement that SED was routed to Competent Institution Result, individual is covered Answer size (KB) /Compressed XML file (KB) 0.5/1 0.5/1 0.5/1 0.5/1 2/NA 0.5/1 0.5/1 0.5/1 0.5/1 2/NA Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 6 of 12

343 FILE PACKING FACTOR As it is the current practice in TESS, compressed SED will be packed in compound file, meaning that a compound file will consist of several compressed SED. With the exception of (i) the checks for healthcare entitlement and (ii) postings, both of which will be exchanged as single documents on-line in a just-in-time fashion, we have assumed that all other SED, including all acknowledgements, will be exchanged in compound files, with a file packing factor of 50. It means that each compound file will contain 50 compressed SEDs or acknowledgements FILE ENVELOPE OVERHEAD SEDs encoded in XML and compressed will be contained in larger envelope files for a variety of reasons, including for instance envelopes for digital signatures and so one. What is likely to be exchanged in the EESSI network will not be raw XML-encoded and compressed SED files, but such files wrapped in file envelopes. Therefore, the file envelope will increase the file exchanged via the network. We have assumed a 25% file envelope overhead. It is noted that the file envelope overhead is a complex issue that very much depends on the particular choices to be made for the EESSI message format WEB SERVICES OVERHEAD While Web services is not a particular choice that necessarily must be adopted in EESSI, they enjoy such a broad industry acceptance, that an EESSI architecture without relying on them will risk being considered as outside the mainstream, and becoming legacy even before its implementation. In this respect, the impact of Web services on the network data traffic must be considered. Web services, which rely on SOAP and SOAP attachments, bring their own overheads. SOAP attachments are typically encoded (in Base64) which adds a 33% overhead in the message size. Other layers of Web services, such as WS-Security add their own overhead. We have assumed a Web services overhead factor of two (2), which means that Web services will add twice as much data traffic for their own implementation purposes, making the total data traffic 3 times the size of the original data EESSI PROTOCOLS OVERHEAD In addition to the actual exchange of SED in the EESSI network, there will be exchanges of other types of messages, mainly control types. For instance, data traffic due to queries to the EESSI Directory and replication of Directory trees to access points constitute additional traffic. Checking the status of an access point is another type of control message. We have lumped all additional data traffic as EESSI protocol overhead characterised by the volume and message overhead factors. The protocol volume overhead factor represents the volume of additional data traffic, and the protocol message overhead factor represents the additional control messages. We have assumed a protocol volume overhead factor of 50% and a protocol message overhead factor of 100%, meaning that the EESSI protocols will increase the data traffic by 50% and double the number of messages. Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 7 of 12

344 1.3. DATA TRAFFIC ESTIMATIONS Table 6 presents an analysis of the EESSI data traffic based on the above assumptions. Table 7 gives the mathematical formulas used to calculate the corresponding rows of Table 6. Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 8 of 12

345 Table 6: EESSI data traffic analysis per different sector Type, A: Assumption, C: Calculation No Type Item Pensions Health Entitlement to health Family benefits Unemployment Postings 1 A Number of SED exchanged 3,300,000 5,300,000 2,500,000 1,500,000 1,500,000 1,200,000 2 A SSED compressed size A File packing factor A Results/acknowledgement files per SED A Size of result/acknowledgement file A Acknowledgement files packed in a single file C Total volume of SEDs exchanged (KB) 16,500,000 26,500,000 5,000,000 7,500,000 7,500,000 2,400,000 8 C Total size of results/acknowledgement files exchanged (KB) 6,600,000 10,600,000 5,000,000 3,000,000 3,000,000 2,400,000 9 C Number of compound SED files 66, ,000 2,500,000 30,000 30,000 1,200, C Number of compound results/acknowledgement files 132, ,000 2,500,000 60,000 60,000 1,200, A File envelope overhead 25% 25% 25% 25% 25% 25% 12 A Web services overhead 200% 200% 200% 200% 200% 200% Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 9 of 12

346 13 C Total size of data traffic (KB) 86,625,000 99,375,000 18,750,000 28,125,000 28,125,000 9,000, C Total number of messages exchanged 198, ,000 5,000,000 90,000 90,000 2,400, A Protocol volume overhead factor 50% 50% 50% 50% 50% 50% 16 A Protocol message overhead factor 100% 100% 0% 100% 100% 0% 17 C Additional data traffic due to EESSI protocol 43,312,500 49,687,500 9,375,000 14,062,500 14,062,500 4,500, C Additional messages due to EESSI protocol 198, , ,000 90, Total network data traffic (KB) 129,937, ,062,500 28,125,000 42,187,500 42,187,500 13,500, Total number of messages 396, ,000 5,000, , ,000 2,400,000 Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 10 of 12

347 Table 7: Formulas used in calculations of data traffic volume No Row Formula (Numbers refer to row- number of Table 6 ) 7 Total volume of SEDs exchanged (KB) [1]*[2] 8 Total size of results/acknowledgement files exchanged (KB) [1]*[4]*[5] 9 Number of compound SED files [1]/[3] 10 Number of compound results/acknowledgement files [1]*[4]/[6] 13 Total size of data traffic (KB) (1+[11])*(1+[12])*([7]+[8]) 14 Total number of messages exchanged [9]+[10] 17 Additional data traffic due to EESSI protocol [13]*[15] 18 Additional messages due to EESSI protocol [14]*[18] 19 Total network data traffic [13]+[17] 20 Total number of messages [14]+[19] Table 8 summarises the results of Table 6 in terms of synchronous and asynchronous data traffic; the former concerns the check for entitlement to healthcare and posting that must be perform on-line; the latter concerns all other sectors for which the reply to an SED, which itself is another SED, will be sent in more than a working day. Asynchronous data traffic represents about 90% of the traffic volume but only 16% of the total number of messages. This is not surprising, as we have assumed that 50 SEDs are packed in a message. On the other hand, the entitlement to healthcare and postings are formulated each in an exchange of a single message, so they have far higher contributions to the total number of message. Table 8: Aggregated data traffic Item Asynchronous traffic Synchronous traffic Totals Total annual volume (KB) 363,375,000 41,625, ,000,000 Total annual number of messages 1,392,000 7,400,000 8,792,000 Total volume per month (GB) Total number of messages per month 116, , ,667 Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 11 of 12

348 It is worth comparing the above data traffic estimations with those of the Taxation and Customs DG CCN/CSI network. Table 9 gives indicative figures of data traffic in the latter network for three months. It should be noted that the CCN/CSI messages are not transported by Web services but through message-oriented middleware (IBM MQ-Series). Table 9: Data traffic in CCN/CSI network Month Number of messages exchanged in thousands (1,000) Volume of data (GB) May , April , May , The above comparison between EESSI and CCN/CSI indicates that EESSI will impose reasonable bandwidth requirements to the EESSI backbone network. Call for Tender VT/2008/019: Tender Specifications, Annex T3 Page 12 of 12

349 EUROPEAN COMMISSION DIRECTORATE-GENERAL Employment, Social Affairs and Equal Opportunities Social Protection and Integration Coordination of Social Security Schemes, Free Movement of Workers Open Call for Tender VT/2008/019 Informatics services and products in the context of the EESSI (Electronic Exchange of Social Security Information) project Technical Specifications Annex T 4 Data Centre Guidelines Call for Tender VT/2008/019: Technical Specifications Annex T4

350 EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Infrastructure Directorate Data Centre European Commission Overview of the usage of the Information System Hosting Services of the Data Centre Date: 25/11//2005 Approved by: TE KOLSTE Georges-Eric Reference Number: 3771V.3 Commission européenne, L-2920 Luxembourg. Telephone: (352) Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2)

351 TABLE OF CONTENTS 1. INTRODUCTION Overview How to read this document Mission and Services of the Data Centre Organisation of the Data Centre Contact ARCHITECTURE MANAGEMENT PROCEDURES Introduction Application Lifecycle Hosting Request and the Change Management Process Incident Management for ISHS Product Management Data Protection Security Service Level Agreement Preventive maintenance Configuration data Acceptance testing Reception Procedure - Production check list for new IS and major releases Publishing guidelines on Europa and IntraComm Monitoring User Statistics Data Centre Resources Usage User statistics Web Consultation INFRASTRUCTURE Introduction Servers Time Servers Domain Name Servers ORACLE Name Servers DMZ Storage Contingency Load Balancing Backup Service for the local servers in the DGs Environments Overview of the usage of the Information System Hosting Services of the Data Centre - Document Version dated 25/11/2005 Page i

352 5. TECHNOLOGICAL ENVIRONMENTS Introduction Access Layer Web Servers Coldfusion WebLogic Business Objects Oracle UNIX/LINUX Windows SMTP relays for applications Mailbox access for applications ECAS & LDAP Active Directory Corporate Web Content Management System SAS FTP store Overview of the usage of the Information System Hosting Services of the Data Centre - Document Version dated 25/11/2005 Page ii

353 Table of Figures Figure 1 - Organisation Chart of Data Centre Figure 2 - Data Centre Architecture Figure 3 - Incident Management Figure 4 - Organisation of the ISHFO Figure 5 - ColdFusion Hierarchy Figure 6 - WebLogic Domain Figure 7 - Failover Architecture Document History Version Date Comment Modified Pages /09/2005 Creation of the Document. ALL Contacts Name DG/Service Phone Number General Mailbox DIGIT/A/3 digit-dc-guidelines@cec.eu.int N/A General Disclaimer This document is the property of the European Commission. The information provided in this document allows all interested parties to see the guidelines for Information System Hosting. The content of this document may be subject to rapid changes for a variety of reasons. The European Commission can not be held liable for the consequences of any reliance on the information provided or for any inaccuracies in such information. All or part of the document may not be copied without prior agreement by the European Commission and without specific reference to the latter as well as the source of the extract. The master document is written in English, if translations of this document exist in other languages, the reference will be this document. Overview of the usage of the Information System Hosting Services of the Data Centre - Document Version dated 25/11/2005 Page iii

354 1. INTRODUCTION 1.1. Overview The Commission communication on IT Governance (SEC(2004)1267) provides a framework for increased collaboration between DG DIGIT and the DGs. Within this context this document contributes to developing a common approach in the specific area of hosting information systems in the Data Centre. The Data Centre provides a range of services to Directorates General, other European Institutions and Agencies. These services include the hosting of both corporate and specific information systems (Information Systems Hosting Service). The purpose of these guidelines is to define, for the Information Systems Hosting service, the range of services offered by the Data Centre and the conditions under which they are made available to Clients. The Data Centre hosts a very large number of information systems. In order to make this manageable it is evident that a certain degree of standardisation and discipline is necessary, particularly in order to ensure that the appropriate performance and availability levels are maintained, and that common resources can be shared conveniently between different systems, without adversely impacting the services offered to others. The Data Centre is currently adapting its processes so as to implement ITIL recommendations for Service Delivery and Support. The complete set of guidelines will be reviewed and republished as a whole by the Data Centre every semester. These guidelines provide the framework for Information System Owners, Customers and their development teams to define and manage their requests for services of the Data Centre. They may be made available to subcontractors on condition that they have signed a Non Disclosure Agreement (normally part of the general terms and conditions of the contract). These guidelines apply to requests for hosting initial and major releases of mission critical Information Systems and will be completed with specific procedures for managing minor releases. The IT strategy of the Commission is elaborated in detail since 2005 by DG DIGIT in close collaboration with the services as foreseen in the Communication. The Data Centre s procedures will be aligned with these decisions particularly concerning the annual Schéma Directeur exercise and development methodologies. These guidelines will be continuously updated to reflect these changes How to read this document If you are an Information System Owner or a Supplier, you will be mostly interested in Chapters 1, 2 and 3: Chapter 1 gives a brief overview of the Data Centre. Chapter 2 describes the Data Centre s architecture. Chapter 3 covers the management procedures to be followed when interacting with the Data Centre (how to introduce a request for hosting, how to report an incident,). If you are an Information System Developer, you will be mostly interested in Chapter 4 and chapter 5. Chapter 4 explains the infrastructure currently available at the Data Centre. Chapter 5 covers the technological platforms supported by the Data Centre and gives guidelines to be followed during the application development lifecycle. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 4 Document Version dated 25/11/2005

355 1.3. Mission and Services of the Data Centre The Data Centre is a service oriented unit providing the Commission with a corporate, secure, reliable and high performance IT infrastructure to support 24h/24 the information systems and services needed to implement the e-commission. The services provided by the Data Centre are: Corporate information system hosting particularly for the mission critical systems which support Community policies and which underpin the Commission's internal administration; Web dissemination infrastructure particularly for EUROPA, the European Union's presence on Internet and IntraComm (the European Commission's corporate web site); Corporate including calendar and workgroup facilities and with virus protected connectivity to the external world; Corporate infrastructure for applications including office information services. These services include back-up/restore and for a number of critical systems a redundant infrastructure to ensure business continuity in the event of a major incident. The Data Centre's mandate is to ensure the availability, reliability, performance and scalability of these services with the highest levels of security and to foresee their evolution with costeffective, state of the art solutions. The Data Centre provides these services in partnership with the DGs concerned, based on Service Level Agreements with appropriate quality indicators and associated monitoring and measurement procedures. These services are supplied to the end users with the participation of the other units of DG DIGIT s Infrastructure Directorate, particularly concerning telecommunications, so as to ensure end-to-end performance and availability. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 5 Document Version dated 25/11/2005

356 1.4. Organisation of the Data Centre Figure 1 - Organisation Chart of Data Centre - DCIM F.O. (Data Centre Infrastructure Management Front Office): focused on day to day operations and Incident Management related to the Data Centre Infrastructure. DCIM B.O. (Data Centre Infrastructure Management Back Office): focused on Data Centre. Infrastructure architectures, strategy and planning. ISHS F.O. (Information System Hosting Services Front Office): focused on day to day operations and Incident Management related to Information Systems. ISHS B.O. (Information System Hosting Services Back Office): focused on Application architectures, strategy and planning. ISHS Account Management is responsible for the relationship with the DGs regarding their Information Systems. CITIS F.O. (Corporate IT Infrastructure Services Front Office): focused on day to day operations and Incident Management related to Corporate IT Infrastructure Services. CITIS B.O. (Corporate IT Infrastructure Services Back Office): focused on Corporate IT Infrastructure Services architectures, strategy and planning Contact In line with the implementation of a process oriented organisation, the Data Centre has put in place a number of specialised Points of Contacts for processing new requests and for managing incidents For introducing a new request When introducing a new request to the Data Centre, for instance, the creation, modification or transfer of a hosting environment, clients are invited to fill in a request form in the on line system MIRELLA which is the central management tool used by the Data Centre on Information Systems. In case of questions or if assistance is needed, Customers can contact the Account Manager assigned to their DG. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 6 Document Version dated 25/11/2005

357 For reporting an incident or requesting information The Service Desk will ensure follow up of Service Requests or Incidents initiated by creating a ticket in Service Centre, the on line Service Management Tool used by the Commission, either by the Local Helpdesk, the IS owners, or the Central Helpdesk. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 7 Document Version dated 25/11/2005

358 2. ARCHITECTURE The Data Centre offers services which are hosted at two sites with the objective of implementing both failover and emergency backup facilities between them. The schema overleaf represents the 4 layer architecture (access, presentation, application, data base) based on which all Information Systems will be implemented on a secure, redundant, cost effective infrastructure. The Europa, IntraComm and DG Web Servers follow the same architecture. The servers are divided between the two sites and, in case of an emergency, a single site may take over the critical production workload and ensure continual operation in degraded mode. The architecture is based on shared storage with both Network Attached Storage and Storage Area Network configurations. The SAN storage is split between the two sites with synchronous remote mirroring between the SAN arrays via high-speed Dense Wavelength Division Multiplexing connections. The NAS storage is also split between the two sites but with asynchronous remote mirroring. The servers deployed for the hosting service in the Data Centre are mainly UNIX systems (including LINUX). Some hosting on WINDOWS servers is also provided, but this is normally only for very specific projects. The application architecture may use the application components provided by CITIS (eg: , terminal services, active directory) Network connectivity is through the internal Commission LAN (SNET) and WAN (via TESTA or the Internet). Access control is carried out using LDAP (username/password authentication). Stronger authentication is now being implemented with the ECAS project. Access control can also be carried out using SSL via a Remote Access Service. Backup of the Data Centre systems is carried out using cartridges robots. All systems are monitored with an integrated call-out system to technical support teams. Support staff is, where required, on call 24/7. In order to guarantee performance and availability levels, all components of Information Systems must be hosted in the Data Centre. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 8 Document Version dated 25/11/2005

359 . Figure 2 - Data Centre Architecture - Overview of the usage of the Information System Hosting Services of the Data Centre - Page 9 Document Version dated 25/11/2005

360 3. MANAGEMENT PROCEDURES 3.1. Introduction This chapter explains the management processes and procedures that are followed during the application lifecycle so as to ensure that a hosted application is compliant with the strategic guidelines defined by the Commission and DIGIT in different areas including data protection, security, product management and architecture, service level management, configuration management and change management. The chapter is mainly intended for Information System owners in the DGs and Customers Application Lifecycle Information System development is an engineering process with a lifecycle including several phases. For major Information Systems, the following phases are important: Problem statement; Pre-analysis; Feasibility study including a proof of concept; Development; Testing and Training; Operation; Phase out / renewal. Once a new IS is hosted, there is a loop between the Testing & Training phase and the Operation phase for implementing new releases. These phases will be adapted in line with the RUP methodology in the next version of this document. It is desirable that the Data Centre is involved, at the earliest stage of Information Systems projects so that: The architecture may be defined in line with these guidelines when the hosting request is presented to the Data Centre; The required infrastructure for the Information System may be acquired and installed in time; Acceptance procedures may be agreed and actions linked to performance and functional tests be planned; The SLA can be signed before the operation phase starts. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 10 Document Version dated 25/11/2005

361 3.3. Hosting Request and the Change Management Process Hosting Request In line with the Commission decision on IT Governance, DGs should include initial requests for hosting information systems in the Data Centre in their annual Schéma Directeur exercise. The subsequent detailed hosting request should be introduced by the Customer responsible as early as possible in the development life cycle. An application schema is required so as to understand the application architecture, the software components and data access paths. It is very important for the Data Centre to understand the architectural requirements so that servers can be dimensioned adequately at each level of the architecture (access, presentation, application, and database). Depending on the request, additional technical information may be necessary to ensure that it is well understood by the Data Centre and can be handled with maximum professionalism. Indeed, it is crucial for the Data Centre to receive information on the architectural requirements and products, on the evolution of disk usage and workload, on the criticality of the application (availability, fail over, contingency) and potential security issues (external accesses, ) so that appropriate solutions can be implemented and a reliable capacity plan can be prepared in terms of infrastructure and staffing. A minimum delay of 2 weeks is required by the Data Centre to deliver a new environment in the simplest case. This delay is of course dependent on the request (need for additional equipment to be delivered ) and it is essential that the DGs introduce their hosting requests as early as possible in the application life cycle. To introduce a hosting request an electronic THM form (Transfer Hosting Modification) should be filled in using a technical template. Also, one additional template per domain should be provided.(ex: WebLogic, ColdFusion, webi, ORACLE).If help is needed when filling in a THM form, DG are invited to contact their corresponding Data Centre account manager for assistance either by phone or via the functional mailbox. A technical project leader (or Change Coordinator in ITIL terminology) is also appointed within the Data Centre for coordinating the implementation of every request for change Change Management Process Every hosting request creates a change in the Data Centre infrastructure and that change has to be managed in a controlled way. To achieve this, a change management process has been designed in alignment with ITIL recommendations including a Change Advisory Board with members of the Data Centre management team. In this process, several checkpoints are foreseen to ensure that a request for change is handled systematically. Concretely, 2 main checkpoints are defined by the CAB: 1. CAB approval for starting change implementation: When a request for change is received, it is essential that the request from the client is clear and complete so that the impact on Data Centre infrastructure can be assessed accurately and the Data Centre can make a reliable capacity plan (machine workload, disk usage, staffing). Also, it is essential that the demand is aligned with the choices regarding architecture, standard products in the product catalogue and security policies. It is Data Centre policy that, in order to guarantee service levels, all components of Information Systems must be hosted in the Data Centre. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 11 Document Version dated 25/11/2005

362 CAB approval will be given for implementing the request based on these criteria. Appropriate planning is required for implementing end-to-end monitoring and performing functional, performance (load/stress tests) and failover tests so that the implementation will be done right first time. 2. CAB approval for putting an application into production: CAB approval will be given as soon as the tests mentioned above are performed successfully, the monitoring is in place and the configuration management database is updated. To ensure that a systematic approach is adopted for signing off, a checklist will be used. For more information regarding the change management process, contact the management team. The changes initiated by DIGIT services (ex.: change of IP address) also follow the same phases. Only the procedures within a phase are adapted depending on the type of change (simple/multi domain, urgent ) Incident Management for ISHS What is Incident Management? Information Systems Hosting Service incident management covers three areas: Incidents; Service requests; Complaints. The following definitions apply: An incident is any event which is not part of the standard operation of a service and which causes an adverse impact on the quality of service or the security of an Information System and/or DC components. A service request is a request from a user for support, delivery, information, advice or documentation, not involving a failure in the IT infrastructure and not having an impact on the configuration items. A complaint is a communication from the user about the quality of the service delivered by the ISHS. There is one additional important term in incident management which is Configuration Item. A CI is the item to which the incident refers. e.g. it can be an information system, a component of the IS like Oracle or similar. CIs are predefined in the Service Management Tool and incidents are linked to them when they are opened. In SMT, there are two types of CIs: Initial CI: is entered by the originator of the incident; Failing CI: is entered by the Data Centre when the impacted CI is identified. Incidents are opened by users via their local help desk or via the central help desk. They are processed primarily by the ISH Front Office with support from the ISH Back Office (see below). ISH Account Management has no role in resolving incidents. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 12 Document Version dated 25/11/2005

363 Figure 3 - Incident Management - The organisation for handling incidents is: Front Office (ISHFO) incident management service desk (ISHSD) 1 st line support groups (ISHSGs) 2 nd line Back Office (ISHBO) planned activities and 3 rd line support The ISH Service Desk takes care of receiving incidents, assigning them to the ISH Support Groups and makes the necessary follow-up. The ISHSGs solve the incidents while keeping contact, whenever required, with the ISH Back Office. The detailed organisation of the ISH Front Office is shown above. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 13 Document Version dated 25/11/2005

364 Figure 4 - Organisation of the ISHFO - When is the ISH Service Desk available? The ISHSD is available between 08:00AM and 07:00PM during normal working days. Outside the period mentioned above, critical and urgent incidents regarding the Data Centre ISHS should be sent to the Central Helpdesk. Normal incidents should be reported on the next working day. When recorded incidents are categorised and prioritised. Who can communicate incidents to the ISHS? Only reporting users of the ISHS can communicate incidents, service requests and complaints to the ISHS. The following are defined as reporting users of the ISHS: The hosted information system support group within the DG (information system owner), provided that the DG has access to SMT (see below); The DG Local Help Desk; The Central Help Desk. It is important to note that the end-users of an information system are not considered as reporting users of the ISHS and, as such, they should contact the local help desk if they have an issue with an information system. It is the local help desk responsibility to follow the DG s internal procedures for handling those issues. HOW TO COMMUNICATE INCIDENTS TO ISHS All the incidents for the ISHS must pass through the ISHS Service Desk (ISHSD). The incidents can only be treated if communicated to the ISHSD through the EC standard incident management tool SMT, which means that each incident before it can be considered - must have a SMT assigned incident number. It also means that incidents arriving via current functional mailboxes or private mailboxes or via telephone will not be accepted. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 14 Document Version dated 25/11/2005

365 There are two channels to communicate an incident to the ISHSD, depending upon the availability of SMT to the reporting DG. The following explains both cases. DGs that have access to SMT DGs that have access to SMT are able to create and assign incidents, service requests and complaints directly in SMT and to assign them to the ISH Service Desk. In order to ensure a correct reception of the incident by the ISHSD, the subject line in the incident should be formatted as follows: <application name> <operating system environment> <short meaningful description of the incident>. If an application has several components, a clear identification of the failing component must be given. For incidents with critical or urgent priority a special procedure must be followed. This procedure is described below. DGs that do not have access to SMT DGs that do not have access to SMT must pass through the Central Help Desk. They should communicate incidents, service requests and complaints to the CHD following the standard procedure. The CHD will then take care of entering the incident, service request or complaint into SMT and will assign it to the ISHSD. For critical and urgent incidents, the CHD will apply the same procedure as described below. Data quality It is of vital importance that data registered for an incident is meaningful. In particular, the following fields should be filled with meaningful information: Initial CI; Subject; Description. The subject is used both in call dispatching/resolution and in statistics. In order to improve the resolution time and in order to produce meaningful statistics (the subject field is printed out as part of a report showing incidents by DG and by information system), the subject line should be compiled as follows: <application name> <operating system environment> <product/technology> <short meaningful description of the incident>. E.g. <application> <Solaris> <Oracle> <application does not respond>. The Description field should contain a meaningful detailed description so that neither the ISHSD nor any support group has to call back the reporting user to understand the nature of the incident. It is very important, for an application having several components, to clearly identify the failing component. When a critical or urgent incident is assigned to the ISHSD or to the CHD, the reporting user should follow up the assignment of the incident with a telephone call to, respectively, the ISHSD or the CHD to ensure that the right attention has been given to the incident. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 15 Document Version dated 25/11/2005

366 HOW INCIDENTS ARE FOLLOWED UP The ISHSD will follow up the progress of incidents and whenever required it will keep the reporting user updated. This is particularly true if for any reason an incident takes longer than expected to be resolved. During its working hours (from Monday to Friday 8:00AM to 7:00PM), the ISHSD will follow up on incidents depending upon priorities as follows: Critical: the ISHSD will follow them up immediately with ISHS Support Groups. The targeted resolution time is of two hours after reception of the incident (not committed to in case of serious hardware failures or incidents that need in-depth analysis of the cause); Urgent: the ISHSD will follow them up within one hour with ISHS Support Groups. The targeted resolution time is of four hours (not committed to in case of serious hardware failures or incidents that need in-depth analysis of the cause); Normal: the ISHSD will follow them up with ISHS Support Groups within 4 working hours. The targeted resolution time is of eight working hours (not committed to in case of serious hardware failures or incidents that need in-depth analysis of the cause); Low: no follow up is done by the ISHSD; Scheduled: no follow up is done by the ISHSD. The follow up information will be sent to the reporting user by . Outside the working hours of the ISHSD, the Central Helpdesk should be called by the DGs instead of the ISHSD. The CHD is open 24/24 7/7. At the same time after the incident has been assigned by the ISHSD to a support group of the ISHS the support group itself will have a direct contact with the reporting user if additional information is required. Finally, the reporting user (please be aware of the definition of user given above) can contact the ISHSD by if incident status is required. In that case, the incident number must be specified. Due to the potential additional heavy load upon the ISHSD, it is recommended to send those requests only in critical situations. How to escalate an incident? If the DG has a perception that an incident is not correctly or timely managed by the ISHSD, the following escalation sequence may be activated: ISHS Front Office Team Leader: ISHS Front Office Manager: ISHS Service Manager Product Management DIGIT maintains a product catalogue kept up-to-date with all the approved products that are supported. The product catalogue is updated regularly depending on the framework contracts signed by the European Commission, and product life cycles. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 16 Document Version dated 25/11/2005

367 Products not in the product catalogue are not supported by the Data Centre. Moreover, there can be a delay from when a product appears in class B or class C in the product catalogue and when it is actually available and supported in the Data Centre. This is dependent on the training of the technical people, the definition of the architecture and setting up of the new product within the Data Centre infrastructure. In the case of class B products, competence centres are created in the Data Centre to support them. In the case of class C products, the Data Centre hosts applications with these products but adhoc support will be provided in agreement and close collaboration with the requesting client Data Protection Any personal data included in the Contract will be processed in accordance with the requirements of Regulation (EC) 45/2001 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movements of such data. The data will only be processed for the purposes of the performance, management and follow up of the Contract by the Contracting authority (ies) without prejudice to a possible transmission to the bodies in charge of a monitoring or inspection task in conformity with Community law. The Contractor may, upon request, obtain the communication of his personal data and rectify any inaccurate or incomplete personal data. Should the Contractor have any queries concerning the processing of his personal data, he shall address them to the Contracting authority (ies). As regards the processing of his personal data, the Contractor has a right of recourse at any time to the European Data Protection Supervisor. The Contractor shall comply with Regulation (EC) 45/2001, notably article 23 thereof, and Council regulation (Euratom, EEC) N 1588/90 of 11 June 1990 on the transmission of data subject to statistical confidentiality to the Statistical Office of the European Communities (OJ No L151, , p. 1)". As in general Regulation 45/2001 is applicable to all contracts, it is important to understand in a more detailed consideration, that there are 2 main issues a legal data protection clause has to cover in contracts: The processing of personal data by the institution in the contract documents, including any attachments; The processing of personal data under the responsibility of the institution during the execution of the contract; If in this context the sub-contractor is a Processor, the reference to Article 23 on "Processing of personal data on behalf of Controllers", pointing itself to articles 21 on "Confidentiality" and 22 on "Security", is important; If in this context the sub-contractor also has to act as a Controller subject to national data protection law the reference to Articles 7, 8 or 9 on "Transfer of personal data", is important. The statutory staff and contractors working in the Data Centre have been duly informed on legal data protection provisions applicable to the Data Centre. Contractors must respect the Data Protection Regulation by including a legal clause in their contract Security Several levels of security measures are in place. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 17 Document Version dated 25/11/2005

368 Physical access control Security guards manage machine room access, access is only authorized by the Head of Unit UNIX production systems In order to check the integrity of the UNIX environments, an automated routine is run continuously to verify each platform s UNIX configuration files and overwrites the files if a change is detected Secure environment System administrators keep ROOT passwords; application owners have no access to the system with this role Password policy Users should be prompted by information systems to use strong password in their logons. Strong passwords have the following characteristics: Minimum length 8 alphanumeric characters; Mixture of upper/lower case and special characters; Maximum password age set ( < 90 days) Information system classification The classification is based on Commission decision C (95)1510 on protection of information systems. Under the current regulations, none of the data contained in the information systems hosted in the Data Centre is classified RESTREINT-UE or higher. All systems process unclassified data that do not require higher security measures than those currently implemented in the Data Centre. Requests to host applications processing data classified RESTREINT-UE or CONFIDENTIEL-UE or that require non standard measures must be addressed in the first instance to the Head of Unit of the Data Centre Service Level Agreement The Data Centre is currently working on the preparation of a service catalogue to structure its offer as well as on the implementation of monitoring to measure indicators (KPIs) and check them against committed service levels. The measurement of these KPIs will be the basis for defining service improvement actions. Data Centre policy is to define with the client the service level that is required depending on the criticality of the information systems to be hosted, specifically regarding availability, monitoring, fail over, contingency and disaster recovery. For instance, it may not be necessary to foresee systematically 24/7 availability with contingency for each application. Through the negotiation process with ISHS account managers, SLAs will be defined and related conditions to be fulfilled by both parties (Data Centre and DGs) will be agreed so that service levels can be committed to by the Data Centre. For example, the Data Centre will give commitments regarding the availability of applications if changes are implemented on the production environments under its full control. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 18 Document Version dated 25/11/2005

369 3.9. Preventive maintenance No Break and Air conditioning maintenance The Data Centre provides 24 hours/day, 7 days/week, the technical infrastructure (servers, disc space, software, tools for back up, monitoring and technical support) necessary for hosting the Information Systems of DGs. This infrastructure needs permanent air conditioning and a no-break power supply on both sites. To guarantee operations the Data Centre organises annually several preventive maintenance interventions on the air conditioning and on the power supply. Customers are informed in advance of the planning for these interventions and the possible risks for their applications. Regarding the to ensure the same availability for the contingency site and for the different sites in Brussels, one annual preventive maintenance operation per site is organised. All maintenance dates are fixed each year in December for the following year. An information note is sent in advance to all the Customers to explain the impact of the intervention Maintenance interruptions for Data Centre environments In addition to these planned maintenance interventions required for testing contingency plans, installing patches and cleaning file systems, the Data Centre reserves the right to apply emergency interventions and system maintenance with minimum notice of : 5 (five) working days for planned interventions; As soon as possible during the day if an emergency intervention must take place after 07:00 PM; Without prior notice if necessary Configuration data It is essential to keep systematically the information up-to-date whenever a configuration item is modified, added or removed within the Data Centre Infrastructure. It is foreseen in the change management process to systematically update the configuration management database when a new change is implemented. The benefit is that the impact of an incident or a change can be assessed within the Data Centre due to the links specified between the configuration items. Also the related documentation should be kept up-to-date Acceptance testing Before authorizing a new application to be put into production, the Data Centre has to be sure that this new Information System will support the expected workload with acceptable performance and will not degrade the performance of other applications running on the same shared environment. The acceptance tests required by the Data Centre are load tests, performance tests and failover tests if necessary. The load tests are executed by simulating a number of concurrent users. Additional performance tests are executed so that the resource consumption per process is measured. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 19 Document Version dated 25/11/2005

370 A simplified procedure for testing corrective patches on existing applications will be defined by the Change Manager Reception Procedure - Production check list for new IS and major releases The reception procedure consists of a series of items in the form of a production checklist. Each item in the list should be well documented as part of the implementation of new services and applications. The CAB will use this production check list to decide when a new information system is ready to be put into production (see chapter 3.3 Hosting Request and the Change Management Process). The objective of the production checklist is to assure that every necessary element in relation to the administration of the hosting environment is well documented and available for all services before production is authorised. It is intended that the input for several of these items is supplied by the client with the initial request for hosting (i.e. part of the Mirella form for new hosting requests). Item 1. Architecture and description The service/application architecture should be documented with a description of its purpose, clients and a simple flowchart illustrating the interaction between the various components. Information concerning co-existence requirements (e.g. dedicated environment, co-existence only possible under certain conditions, etc.) is specified as an important part of this item. Item 2. Predicted usage patterns The predicted usage pattern (e.g. peak at the end of every quarter) is documented to allow appropriate planning of infrastructure interventions and evolution. The input will serve as a supplement to data obtained through the subsequent production monitoring. Item 3. Installation procedures and routines All installation procedures (from OS to application) are thoroughly documented and tested. Prerequisites for the installation and possible impact on other services (e.g. required server reboots) are included as part of the documentation. Item 4. Software availability, support and licenses The license coverage for all extra-os software products are exhaustively documented, including a description of support channels (directly with supplier, etc.) and classification within the product management framework. Item 5. Backup / Restore Basic and application specific backup and restore routines are exhaustively tested and documented. Item 6. Monitoring / Alerts Exact specification of monitoring needs and methods are defined and documented in collaboration between the Data Centre and the client. End-to-end monitoring is implemented for all application components. Item 7. Reporting With a view to establishing service specific SLAs (or in-line with existing SLAs) reporting mechanisms (e.g. response times, number of users, storage consumption) should be defined, documented and implemented in collaboration with the client. Item 8. Responsibilities (including access rights) Overview of the usage of the Information System Hosting Services of the Data Centre - Page 20 Document Version dated 25/11/2005

371 With a view to establishing service specific SLAs (or in-line with existing SLAs) allocation of responsibilities between the Data Centre and the client is documented. Administration of access rights to the service/application is thoroughly documented, e.g. who defines users, grants access to data, etc. Item 9. Security In addition to the applied base OS security and anti-virus, all application/service specific security requirements are analysed, documented and implemented, e.g. behaviour in relation to personal data, strengthened system lockdown, restricted administrator access, auditing requirements, etc. Item 10. Communication Based on the elaboration of a list of events requiring communication to/with the Client (e.g. service down, response times above preset threshold), the communication mechanism is documented (e.g. mail to Exchange distribution list/functional folder). Item 11. Availability and contingency Each new service or application is accompanied with a description of availability and contingency measures, if required: Failover mechanisms are documented, including a detailed description of associated procedures and responsibilities. A service specific contingency plan is elaborated. Item 12. Operational procedures / contingency Any service/application specific procedure is elaborated and documented, e.g. Clean up of temporary files; Procedure for move from test to production; Procedure (internal within the Data Centre, also between the Data Centre and the client) for activating the contingency if necessary. Item13: Technical documentation This should document the application as it has been implemented in the Data Centre (change of IP addresses of the servers, the flows...) Publishing guidelines on Europa and IntraComm For publishing data on the Commission s web sites, a set of rules has to be followed for the organization of the data. These guidelines cover: Introduction; Data structure for web pages; Using ColdFusion; Weblogic Infrastructure; Uploading data; Updating the dissemination sites; Overview of the usage of the Information System Hosting Services of the Data Centre - Page 21 Document Version dated 25/11/2005

372 Staging manager; CGI scripts and programs; Using the search engine; Publishing data bases on the Web; Working with the reverse proxy servers; Configuration related issues; Running "local" web servers on the IntraComm platform; Recommendations Monitoring Service Description The monitoring service is responsible for monitoring the Commission s central computing facilities in order to assure its availability on a 24/24 hours and 7/7 days basis. In this missioncritical context, the monitoring software verifies constantly the performance and availability of the servers hosting applications and information systems, as well as Europa, the European Union s website on the Internet. This software can generate warnings to technical staff based on a very wide range of parameters. This allows anticipation and avoidance of most problems potentially affecting the servers performance, thus preventing server crashes and the unavailability of applications and information systems. The monitoring service is composed of 3 layers: Information collection: specific checks are performed at regular intervals, either locally, e.g. to verify the file system usage, or remotely, e.g. to verify the availability and response time. Alert management: for each parameter verified, it is possible to define thresholds that will trigger an or SMS message to the people concerned. This mechanism allows potential problems to be anticipated and to correct them before services will be impacted. Reporting on collected information: the objective is to give the Data Centre and the DGs a regular follow-up on the quality of service offered. It centralises all relevant parameters and provides consolidated reports. The analysis of the reports allows the verification and the follow-up of the quality indicators based on objective measurements. It is also possible to verify whether the level of service defined in the Service Level Agreement is being met provided that the corresponding indicators are well defined and measurable What can be monitored? Availability and performance of the operating system and standard basic software. Regular checks are performed at two levels: Overview of the usage of the Information System Hosting Services of the Data Centre - Page 22 Document Version dated 25/11/2005

373 Various parameters of the operating system: CPU usage, file system usage, process availability, etc. Standard and basic software, this includes Oracle, web servers, etc. These checks are mainly performed for internal use. Verification of the availability and performance of information systems. Verification of the availability of information systems is done through end-to-end checks to test whether the different components of the information system are working as expected. The implementation of this kind of monitoring depends strongly on the application logic and usually implies a specific development that can be provided by the Data Centre based on monitoring specifications supplied and maintained by the DGs. The objective is to check automatically the behaviour of an application and to be able to easily detect the failing component(s) so that appropriate action can be taken, if necessary. Verification of the Quality of Service Besides verifying the availability and performance of information systems, it is also important to have indicators on the quality of service offered. One of the key elements for verifying the quality of service consists in measuring the end-to-end response time of an application giving objective figures about the performance end-users are experiencing. This is achieved by installing a monitoring probe in a DG s premises. The DG is responsible for supplying a PC and defining the generic transactions, which will be executed at regular intervals. The transactions simulate an end-user connection and should be as representative as possible. The Data Centre will install the necessary monitoring software. This procedure can be used in the framework of acceptance testing and it is systematically used to measure response times when the Data Centre signs a SLA with its clients. Concerning information systems, which are accessed via Europa, it is possible to measure the availability and performance from the outside world. In other words, it is possible to measure the real end-to-end experience of someone on the World Wide Web who connects to services on Europa. This service is only implemented at the request of the system owner included in the initial hosting request presented to the CAB for decision (see 3.3 Hosting Request and the Change Management Process) User Statistics Data Centre Resources Usage The resource consumption of the Data Centre s servers will be available by host machine, DG, information system and userid on a monthly basis and is currently under construction. These statistics may be used for capacity planning User statistics Web Consultation Statistics on Europa and IntraComm A number of different on line statistics (total number of hits, total number of visits, per DG, etc...) are at the disposal of users. The statistics related to web site consultation on Europa have been developed by DG PRESS. The statistics related to web site consultation on IntraComm have been developed by DG ADMIN Overview of the usage of the Information System Hosting Services of the Data Centre - Page 23 Document Version dated 25/11/2005

374 Statistics on other sites A limited number of standard statistics on other web sites hosted in the Data Centre can be obtained by introducing a service request via the Central Helpdesk or by creating directly a ticket in the Service Management Tool. 4. INFRASTRUCTURE 4.1. Introduction This chapter describes the infrastructure that the Data Centre currently provides. The intended audience are primarily the development teams. After analysing the requirements based on the application architecture provided by the client showing the components and access paths, the Data Centre determines the servers and storage required to satisfy the expected performance and availability levels using the infrastructure described below Servers Based on the contracts signed between the European Commission and its Suppliers, the Data Centre offers a range of UNIX and Windows/INTEL servers UNIX The current range of UNIX servers that can be used for hosting information systems is: Configuration A (entry level) 2 CPUs 6 GB No local storage, only NAS storage. Configuration B (mid range) 4 CPUs 16 GB RAM No local storage, NAS or SAN storage. Configuration C (high end) 8 CPUs 32 GB RAM No local storage, NAS or SAN storage. Configurations A, B and C are essentially used for those components, which can be scaled horizontally as is typically the case for servers used for the access, presentation and application layers. Configuration D (highly scalable ) This server is a machine with a set of domains. Each domain has 1 or more basic building blocks of 4 CPUs and 32 GB RAM Maximum scalability is 18 building blocks (72 CPUs, 576 GB RAM) Overview of the usage of the Information System Hosting Services of the Data Centre - Page 24 Document Version dated 25/11/2005

375 Configuration D is primarily used for those components that have to be scaled vertically as it is typically the case for the database layer. Note: These configurations are given for illustration purposes and are not necessarily up-todate as they are continuously evolving Windows/Intel The current range of INTEL servers that can be used for hosting information systems is: Configuration A (entry level) From 1 x 2.4 Ghz to 2 x 3.0 Ghz processors From 512 Mb to 6 Gb memory From 2 x 36Gb to 5 x 146 Gb Disks Configuration B (mid range) From 4 x 2.0 Ghz to 4 x 2.8 Ghz processors From 1Gb to 16 Gb memory From (8 x 73 Gb + 2 x 36 Gb) to 10 x 146 Gb Disks Configuration C (high end) 8 x PIII Xeon 900MHz processors From 4 Gb to 32 Gb memory 2 x 36 Gb disks These 3 configurations are essentially used for horizontal scaling of components Time Servers All Data Centre Servers clocks are synchronised with a time reference, the reference signal used in the Data Centre is the broadcast radio signal sent by the German atomic clock in Frankfurt. In the Data Centre, there are 4 master time servers in the buildings of the Commission. These servers are the reference for the other 8 Time Servers accessible by clients Domain Name Servers The Domain Name Servers provide the clients with a simple and stable way of addressing machines with a virtualized access to the servers. Only machine names have to be addressed, not the corresponding IP addresses. The use of DNS has the advantage that the changes made within the Data Centre are transparent for the applications addressing machine names instead of fixed IP addresses. Also, it is a mechanism for implementing failover between machines (by mapping the DNS name to an alternative IP address). In the Data Centre, the DNS are highly redundant (8 servers spread over different buildings) and have a high availability ORACLE Name Servers The ORACLE Name Servers provide clients with a simple and stable way of addressing databases by providing a virtualized access to the servers whereby only ORACLE DB names have to be addressed, not the corresponding physical addresses. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 25 Document Version dated 25/11/2005

376 The use of ONS has the advantage that the changes made within the Data Centre are transparent for the applications addressing ORACLE DB names instead of fixed links and addresses. If a database is moved from one server to another by the Data Centre, only the mapping in the ORACLE Name Server has to be updated and the change is therefore transparent for the users. ONS also provide a mechanism for implementing failover between DB servers. In the Data Centre, the ONS are highly redundant and have a high availability DMZ The Demilitarized Zone is a network subset isolated from the Commission network by firewalls. It is used to manage access to the Commissions network and services from the external world (Internet, TESTA, CCN ). The contingency for the DMZ is implemented between Luxembourg and Bruxelles. The current DMZ should be used for gateways between 2 domains and not for hosting applications Storage Service description The Data Centre offers storage capacity associated with backup and disaster recovery depending on the type of environment (production, non production) Technology used: Two storage architectures are currently implemented at the Data Centre: Network Attached Storage; Storage Area Network. NAS A NAS device is a combination of a server (filer) and a large amount of RAID storage. NAS devices are attached to the existing local area network and access to the file systems is made through file-level commands. Two types of network file systems are used: Common Interface File System in the Windows world; Network File System in the UNIX world. The current infrastructure is based on a NAS production cluster in one building, with disaster recovery and backup components in the other. The main advantages of NAS are: Drawbacks are: Easy file sharing; File system localised in one device: simple set-up and maintenance. Performance problems for large database applications; TCP/IP processing needs a lot of CPU; Overview of the usage of the Information System Hosting Services of the Data Centre - Page 26 Document Version dated 25/11/2005

377 NAS is used for: Asynchronous mirroring between 2 sites with a latency time of 5 minutes meaning that 5 minutes of transactions are lost in case of failover. Common Storage Service offering storage capacity to DGs for their needs in the area of office automation. Specific internal Data Centre needs: Static pages for web servers; Files related to COLDFUSION and WEBLOGIC; UNIX home for users to share among several servers; File systems which must be used on several servers, but which can be shared like standard system software (top, gcc, sas,...), ensuring that the same copy is used everywhere. SAN A SAN installation is composed of a high-speed fibre channel network to connect a large storage subsystem to multiple servers. The file systems are located on the servers that run the application and in order to avoid two file systems from different servers unwittingly overwriting each other s data, each storage subsystem is partitioned so that a range of hard disk drives can be logically assigned to a specific server. Currently two RAID levels are used: RAID-1 on EMC SAN, RAID-5 level on HDS SAN. RAID- 1 is more expensive than RAID-5 and has equivalent read performance. However, its write performance is considerably better. RAID-5 gives acceptable performance for most applications, except for sustained load with write operations. The main advantages of SAN are: Reliability because of the redundancies built into the storage subsystem; Scalability because of a common pool of spare disks; Performance and better disaster recovery; Synchronous mirroring between the 2 sites. Drawbacks: High implementation costs; Lack of SAN standards; Interoperability in case of different vendors. SAN is mainly used for: ORACLE and SQL data bases; Traditional file systems which are heavily used and which need high performance. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 27 Document Version dated 25/11/2005

378 The choice of the technology used is made by the Data Centre based on the needs of the application. Thus it is important that the Data Centre receives all the input required to make the appropriate decision for meeting best the user expectations How to obtain the service Storage should be requested by completing the appropriate form in MIRELLA for storage associated with new applications or additional storage for existing applications. It is very important that the Data Centre receives realistic forecasts from DGs on storage usage for the forthcoming 2 years so that it can anticipate needs. DGs should be pro-active by introducing requests early enough so that the Data Centre has the time to implement the required storage. Typically a request for storage capacities exceeding 1 terabyte should be received by DC 4 months before the required availability Contingency The Data Centre may offer contingency with manual or automatic failover for production environments. This service is implemented only if it is explicitly required by the client and clearly indicated in the application schema presented for CAB decision at the time when the hosting request is introduced. Moreover, it is the responsibility of the information system owner to define setup and test the procedures to be applied in case of a disaster. The Data Centre will support the client in preparing these procedures. Fail-over and contingency implementations generate considerable extra-costs and the client should examine whether those implementations are absolutely mandatory based on the criticality of their information systems. If fail-over or contingency is required, then particular guidelines should be followed by the client when developing an application. Additional fail over tests must be undertaken before the application is put into production. For more details, please refer to the guidelines given for WEBLOGIC, COLDFUSION and ORACLE in Chapter 5. In particular, an application should never address directly server IP addresses or hostnames but rather via DNS with a dedicated name in the application. Licences linked to servers should never be used Load Balancing Load balancing may be required to ensure no downtime and/or for providing increased workload scalability. Load balancing is not available at application level for the hosting platforms with the current technologies as actually implemented. However, Load Balancing is available at telecommunication level and may be implemented. If necessary, a request for load balancing will be subject to a feasibility study with regard to the offered service Backup Service for the local servers in the DGs Service description A backup/restore service is offered primarily for the data of the information systems that are hosted within the Data Centre. The main objective of this service is to restore the system, NOT to do data archiving. The service is also mentioned specifically in the technology chapter below. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 28 Document Version dated 25/11/2005

379 The Data Centre can offer a backup service for the DGs: With a standard retention period; With a backup cycle including a full backup and all incremental backups associated until the next full backup; For data from databases managed by the platforms given below (see Technology used) and the data from the file systems. Starting at planned times agreed between the Data Centre and the DGs; Including the management of the cartridges stored within the Data Centre premises. With an average backup performance of 11 GBytes/Hour and an average restore performance of 6 GBytes/Hour performance can fluctuate significantly depending on the number of the files and their size. Restore is the responsibility of the local system administrators in the DGs who execute restore for local servers Roles and Responsibilities between the DG and the Data Centre This following table summaries the responsibilities for backup and restore operations: Activity DG Data Centre Electronic Request Monitoring Restore Make request for backup via Mirella form The DGs get daily mails sent automatically by the backup server about the completion of the backup as soon as completed. If incremental backups have to be restarted, the DGs must ask for this explicitly to the Data Centre. DGs. are responsible for executing the restore. DGs are prompted to inform the Data Centre per about restores that will be launched BEFORE starting so that the Data Centre is aware and does the monitoring. Analysis and CAB decision. Planning for implementation is agreed between the Data Centre and the DG. Contacts the user Monitors the completion of the backup and restarts the failed full backups. This is not systematically the case for incremental backups. Informs DGs about client software updates Monitor restore operation (tape activity) The interlocutors of the Data Centre are normally local system administrators who will be in contact with the backup team of the Data Centre for installation, control of backup, change request, updates etc. Every day, a notification of the backup status is sent to the DGs (at a pre defined address given by the DG at request time) so that DGs can insure daily follow-up of their activity. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 29 Document Version dated 25/11/2005

380 Technology used The software functions in "Client/Server" mode. Given the operating mode, a part of software has to be implemented on each client who wishes to use the backup service. The client part has always to be installed because it constitutes the communication base between the backup server and the client itself Environments Environments are created and maintained for each information system based on its specific requirements. The Data Centre offers typically the following standard environments: Development/test environments used for development, technical and acceptance tests; Production environments. Based on requirements, additional environments may be offered (For example: training, performance, and conformance) For validating the sizing before going into production, load/stress tests are executed on a separate environment within the Data Centre (not accessible for clients) with: A workload simulation tool to simulate user sessions; Other Data Centre internal performance measurement tools; A subset of production data; A copy of a stable application release. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 30 Document Version dated 25/11/2005

381 5. TECHNOLOGICAL ENVIRONMENTS 5.1. Introduction This chapter provides guidelines to be followed when developing new applications so that the integration of these applications within the Data Centre infrastructure will be optimally implemented. The intended audience are primarily the Customer s application development teams. The main software technologies used for applications are described. All requests for these services should be introduced in MIRELLA using the appropriate forms and will be processed by the CAB. Account Managers may be contacted for further information Access Layer Web access to Information Systems Public access - Europa (http) Europa is the web site dedicated to the Internet presence of the European Commission, the infrastructure is managed by the Data Centre Restricted Access IntraComm is accessible only for the personnel employed by the European Institutions. Webgate (HTTPS), the goal is to provide access to restricted sites in an encrypted mode between the webgate DMZ and the client Security conventions Access from external companies A security convention must be signed between the information system owner, the external company and the security directorate. The information on IP Addresses and ports is provided by the Data Centre to the DG within the framework of the change management process Access from other European institutions or Agencies An ad hoc security convention has to be established between security directorate, the Data Centre, the information system owner and the remote institution Miscellanous A direct access, outside the EC network from a server located into the EC network Web Servers The web platforms currently used are Iplanet V4.1 and Apache V1.3.x. Aligned with DIGIT s open source policy, the Data Centre will progressively phase out Iplanet and replace it by Apache. Consequently, no new web application dependent on Iplanet specific technologies will be accepted by the Data Centre Coldfusion ColdFusion is a server-scripting environment for creating Internet applications. ColdFusion has had a successful history in the European Commission since its introduction in Overview of the usage of the Information System Hosting Services of the Data Centre - Page 31 Document Version dated 25/11/2005

382 The Data Centre provides access to this technology and makes available three types of environment: development, test and production. By developing applications at the Data Centre, they will be compatible with the production environment Service description The Data Centre offers a ColdFusion hosting environment for development, test and production use. The production hosting environment consists of three categories of dissemination site: Europa site, Intracomm site and local web site. At present, two full versions of ColdFusion are available in the Data Centre: ColdFusion 5 and ColdFusion MX 6.1 Recommended version: ColdFusion MX 6.1 No new application using ColdFusion 5 will be accepted. New applications should be developed using ColdFusion MX 6.1. ColdFusion MX 6.1 provides greater performance, new features and is stable. ColdFusion 5 and MX 6.0 applications should be migrated to ColdFusion MX 6.1. The Code Compatibility Analyzer must be used to find obsolete and not recommended features. Architecture Please refer to the schema representing the architecture of the Data Centre. Failover is being implemented. CFMX 6.1 ColdFusion MX 6.1 is installed in J2EE mode. This feature allows multiple server instances on a single machine to be defined, each running ColdFusion MX 6.1. Application isolation is the biggest advantage of running multiple instances of ColdFusion MX. Multiple ColdFusion MX 6.1 instances will be deployed on top of the JRun 4 application server. The web server is currently Apache Reverse proxy All access to the ColdFusion public sites is transparently channeled through reverse proxy servers. The reverse proxy servers map incoming HTTP requests to the appropriate web and ColdFusion servers. Classification of hosted applications Applications are classified as follows Public sites Europa Gateway to the European Union The content is managed by DG PRESS (see IPG guide Restricted sites IntraComm The Intranet of the European Commission The content is managed by DG ADMIN. Local sites. The content of these intranets is managed by the DG; Overview of the usage of the Information System Hosting Services of the Data Centre - Page 32 Document Version dated 25/11/2005

383 Secure sites. The content of this extranet is also managed by the DG. For more details, please refer to the chapter on the Access Layer. Environments Development The Data Centre offers a shared development environment to the DGs. This environment is identical to the production environment. It is recommended to develop on the Data Centre s servers to be sure that the application will work correctly on the production environment. Load test Each version of an application must pass load tests. A dedicated environment exists to perform such load and stress tests. Test/Acceptance The acceptance environment should be used to validate a version of the application before it is put into production. Training/Production The Data Centre provides ColdFusion production servers. The target is to dedicate one CF/MX instance to each application Conditions and constraints related to ColdFusion ColdFusion MX6.1 Administration The ColdFusion front office team installs and manages the ColdFusion MX 6.1 servers. To install an application at the Data Centre, the DG must clearly specify their needs: datasources, mapping, scheduled tasks, verity collection. Datasources Only Oracle datasources will be created. The datasource name must be {dg}_{application}_{d/t/p} where: {dg} is the DG s acronym {application} is the application name {d/t/p} is for development or test or production The Oracle datasources can be configured with 3 different types of drivers: DataDirect Oracle Thin Oracle OCI Oracle Name Server should be used. If the application needs to use LOBs, the datasource must be created with the DataDirect drivers included in CFMX 6.1. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 33 Document Version dated 25/11/2005

384 Application JDBC drivers Without LOBs DataDirect or Oracle thin or Oracle OCI With LOBs Only DataDirect (Bug with Oracle thin) With ONS Oracle OCI With LOBs and with ONS No solution Other constraints are specified in the security part of this chapter (see below.). Oracle Datasource CF datasource name Driver Maintain Connections CLOB BLOB {dg}_{application}_{d/t/p} DataDirect or Oracle Thin or Oracle OCI Checked On request On request Long Text Buffer (chr) Blob Buffer(bytes) Allowed SQL By default all the sql commands are allowed. On request, the ColdFusion team can disallow: select, insert, update, delete, create, drop, alter, grant, revoke, stored procedures. Verity collections A Verity collection is a group of information that can be indexed and searched as a set. The ColdFusion team creates the Verity collection and the application can manage it by itself. This search engine is not linked to the Verity Search'97 Information Server which is used as the general search engine on the dissemination sites. The use of this central search engine is to be preferred. The ColdFusion instance of the Verity Search'K2 search engine can be used within the boundaries of applications, in cases where the central search engine cannot give the desired results. Please note that the central search engine does not include cfm pages in its indexes. ColdFusion pages are generated on the fly, and their contents, in principle, will change every time they are requested. It is therefore useless to include this unstable information in the search indexes. Web Services Web services provide remote application functionalities over the net. With a web service, requests to the remote application to perform an action may be made. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 34 Document Version dated 25/11/2005

385 Extensions Java Applets ColdFusion has several Java applets that may be accessed using the CFFORM tag. The ColdFusion team can register specific applets which users can add to CFFORM forms using the CFAPPLET tag. CFX tags CFX tags are custom tags written against the ColdFusion Application Programming Interface (API) to extend and enhance CFML. The ColdFusion team must register specific customized CFX tags prior to using them in ColdFusion application pages. Custom tags Custom tags are allowed. They are implemented in users own directories under site root: the ColdFusion team adds the appropriate path in the ColdFusion server instance. Security Security issues include architecture, data services, file access and sandboxes. Architecture security The first security is on the architecture level. Each production instance of ColdFusion MX 6.1 has its own environment which means: It runs with a unique UNIX user; It runs in its own JVM; It runs only one application. So, each server instance runs an independent application and problems encountered by one application have no effect on other applications. Datasource security The datasource security depends on the type of application. By default all SQL operations are allowed. On request, the following actions can be disabled: select, insert, update, delete, create, drop, alter, grant, revoke, stored procedures File access The complete ColdFusion application (cfm and cfc files) are stored under the /ec/prod/app/webroot directory. According to the type of application, the application will be installed in one of the following directories: Overview of the usage of the Information System Hosting Services of the Data Centre - Page 35 Document Version dated 25/11/2005

386 Figure 5 - ColdFusion Hierarchy - A ColdFusion application cannot write under the /ec/prod/app/webroot directory. But two directories are available to write temporary and permanent data. Temporary data can be written in the work directory: /ec/app/prod/cf_app_doc/work/{dg}/{application} Permanent data can be written in the repository directory: /ec/app/prod/cf_app_doc/repository/{dg}/{application} Sandboxes In ColdFusion MX Enterprise Edition, you can configure multiple security areas on a perdirectory basis. These security areas are called sandboxes. A sandbox is a designated directory of a site to which security restrictions can be applied. Thus, sandbox security allows tags, functions, and resources (for example, files, directories, and data sources) to be specified which can be used by ColdFusion pages located in and beneath the designated directory. All functions are allowed CF TAGS restrictions: see appendix 5 CF FUNCTIONS restrictions: Files/Dirs restrictions: On request, supplementary restrictions can be set on the directories or files. Scheduled tasks The Scheduling facility in ColdFusion MX Administrator allows the generation of static HTML pages to be scheduled. The scheduling facility is especially helpful for applications that do not require user interactions or customized output. ColdFusion developers often use this functionality to schedule daily sales reports, corporate directories, and statistical reports. Response time is fast because the output is an HTML page, not a database transaction. ColdFusion MX allows pages to be scheduled for execution on a daily, weekly, or monthly basis. e.g. specify a time of day for execution; schedule a page to run only once, or on a specified date. Debugging and logging The debugging options are only enabled on the development and on the test server. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 36 Document Version dated 25/11/2005

387 Coding Recommendations Locking variables Developers have to use the CFLOCK tag to ensure the integrity of shared data. SQL commands must NOT be locked! Please refer to the Macromedia website for more information at Cookies CF permits the use of cookies. Nevertheless, for dissemination on EUROPA, the use of cookies is allowed only with certain restrictions: Cookies can only be used without explicit permission if they are limited to the current session; In the exceptional case where a cookie must be stored beyond the current session, explicit permission must be obtained, including an explanation of why it is necessary and the expiry period must not exceed one year. Furthermore the exact information which will be gathered must be listed and an assurance given that it will not be used for any purpose other than the one stated; If refused, the cookie must not simply try again indefinitely, nor must access to the site be refused. XML There are some basic XML editing capabilities available in ColdFusion but when using large files or more complex structures it's not a suitable product. An external parser is recommended for complex XML file generation and manipulation in a production environment. Components A ColdFusion Component (CFC) is an encapsulated ColdFusion application file that resides on the server. CFCs allow developers to make applications and functions available to a variety of clients including other ColdFusion developers, web browsers and web services. The CFCs can support multiple methods, making it easy to group similar functions into a single component Access to environments Data The application can be installed through FTP on the 3 environments development, test and production. The ColdFusion team configures the FTP access. Administration console As the ColdFusion team manages all the resources linked to applications users do not have access to the administration console Log files The application error file is automatically sent to the DGs References Useful links are: ColdFusion MX 6.1documentation: Overview of the usage of the Information System Hosting Services of the Data Centre - Page 37 Document Version dated 25/11/2005

388 ColdFusion technotes: WebLogic Service Description The Data Centre offers the following BEA WebLogic hosting environments on UNIX: development/test, production/training, and performance test. For these environments the Data Centre takes care of numerous aspects which will be developed in the following sections. The Data Centre does the hosting and deployment of EAR, WAR and JAR archives. The Data Centre does NOT create the archives, as it is the responsibility of the client to create them. The Data Centre creates the domains from the WebLogic form information provided at hosting request time. The client will have only access to the development environment through a FTP server. The FTP server will allow J2EE applications to be deployed only on the development server (hot deploy). For the production, a temp directory is present on the development side so that the production is not impacted. The Data Centre creates a domain per application. Generally, the Data Centre deploys all the applications on one server (the admin) to reduce the memory usage. Would split architecture be needed, the requirement should be sent via the Service Desk. The environments are installed on a number of machines dedicated to WebLogic. However, WebLogic domains from several clients share the same machine: as a general rule, there is no machine dedicated to a single application. WebLogic domain types are development / test, production / training and performance test. A machine is dedicated to one type of environment. The choice of where a particular application is put depends on the information given in the request form. The Data Centre is involved ideally in each phase of the development life cycle: Development and Test phases The Data Centre needs to be involved as soon as possible in the lifecycle of the applications to be hosted. This will allow the Data Centre to formalise and possibly, to adapt in an early stage the entire environment details, in order to guarantee the best integration with the production environment. For this purpose, a development / test environment, similar to that of production can be made available. To configure the environments, an installation guide is needed, including test cases to validate the installation. Production phase Before putting applications in production, the Data Centre needs to confirm that the performance tests have been executed successfully. The Data Centre provides hosting for production applications in a failover configuration this means that if a machine goes down, the service can be restarted from another machine within the cluster. In addition to the standard services related to operations, the Data Centre provides additional support and maintenance services to assist clients in case of errors. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 38 Document Version dated 25/11/2005

389 Services to guarantee the operations of the hosted system include: 1. Monitoring All production domains are monitored. 2. Tuning The Data Centre uses a tool to collect information. This information is stored in a CSV file (available from the logs directory). One can easily interpret graphically these values with external tools (Excel for example). Information is available concerning: Connection pool; Heap size; Thread activities; Servlet activities. Additional information may also be collected if specified by the Customer Conditions and constraints related to WebLogic The general architecture for web logic is that shown in chapter 2. Fail over mechanisms are currently operational at server level. The Data Centre makes the latest version of the WebLogic server product available on all machines and this version is available to configure user domains. The same version of WebLogic is installed for all the domains associated with the same application (development and production). The Data Centre manages all domains. All the configurations are made by the Data Centre following user requirements. The FTP server allows applications to be deployed. These applications are in EAR, WAR or JAR format. The explode mode is not supported. The applications should be deployed in the applications directory. A subset of the directory is present inside a domain configuration: Patches : all the files present inside this directory should be jar files. This directory is used to patch the WebLogic API (mail API by example) Lib : all the files present inside this directory should be jar files. The other files are not loaded by the start script. All the elements of this directory are placed after the weblogic.jar in the classpath. This directory is used to install libraries for all your application as this one is present in the classpath of the server (server side not application side). Classes : this directory is used to store properties files used by application settings in relationship to the Data Centre environment. It is recommended to use this directory instead of storing the properties files in applications. Overview of the usage of the Information System Hosting Services of the Data Centre - Page 39 Document Version dated 25/11/2005

390 Default values are as follows: Parameter JAVA_OPTIONS_AS LANG START_MODE Database Driver -ms128m -mx256m Value if other non standard values are requested they must be justified by stress test results. en_us DEV = false (auto deploy) PROD : true Oracle Thin Driver For more informations, see this link The Domain structure is as follows References Figure 6 - WebLogic Domain - Useful links are: Overview of the usage of the Information System Hosting Services of the Data Centre - Page 40 Document Version dated 25/11/2005