P_BUC_06_Mainproc_Specification_v4.1.0

EESSI Business Use CaseEESSI Business Use Case EESSI Business Use Case EESSI Business Use Case P_BUC_06Notification of Pension InformationP_BUC_06Notification of Pension Information P_BUC_06 Notification of Pension Information P_BUC_06 Notification of Pension Information Table of Contents Table of Contents 2 Document Control Information Settings Value Document Title: Business Use Case P_BUC_06 – Notification of Pension Information Project Title: EESSI (Electronic Exchange of Social Security Information) Project Document Author: European Commission, DG EMPL F5 System Owner: European Commission, DG EMPL D2 Doc. Version: v4.1.0 Sensitivity: Public Date: 03/08/2018 Document history: The Document Author is authorized to make the following types of changes to the document without requiring that the document be re-approved:

Editorial, formatting, and spelling
Clarification To request a change to this document, contact the Document Author or Owner. Revision Date Created by Short Description of Changes v0.1.0 19/03/2016 Phil Cummings First Draft v0.2.0 10/05/2016 Cristina Ezaru Incorporated review received from AHG: 1. Updated Business Scenario 2. Branch 5 : Case Owner is responsible for this scenario 3. Removed P4000 and P10000 from Attachments Allowed table and SED Versioning table 4. BUC correct name updated in all document 5. Updated Actors & Roles 6. Updated Main Scenario->Identify Participants step 7. Proposal to remove P8000 and P9000, branch3, branch13, branch20, branch21, branch22, branch23, branch27, branch28, branch29, branch30 – the BUC is not yet updated 8. Updated Branch15: Add Participant is allowed also for the Counterparty 9. Branch 31 removed 10. Minor formatting, date, version and grammar changes v0.3.0 06/07/2016 Cristina Ezaru Alignment to the standard description and layout of the BUC. v0.4.0 14/07/2016 Cristina Ezaru Incorporated review received during the AHG meeting (13/07/2016) 1. Rewording Purpose 2. Branch14 updated: removing participants should be able to any participant (within their own MS) 3. updated Sub-process table: AD_BUC_07 is used 4. Proposal to remove P8000 and P9000, branch3, branch13, branch20, branch21, branch22, branch23, branch27, branch28, branch29, branch30 5.Proposal to add P4000 and P10000 v0.5.0 25/07/2016 Carine Molle Alignment to the standard description and layout of the BUC. v0.6.0 10/08/2016 Cristina Ezaru

Incorporated review received from AHG: 1. P8000 and P9000 removed, with all related branches: Branch3, Branch20, Branch21, Branch24, Branch27, Branch28 2. Branch13 removed 3. Alternative Scenario updated: Branch6 added – Transfer of Additional Information (P10000) 4. Added Branch32, Branch33, Branch34 v0.7.0 30/09/2016 Cristina Ezaru Incorporated review received during the AHG meeting (29/09/2016) 1. Branch4 removed, as well as the related branches: Branch22, Branch29 2. Branch2 updated: "at [step 3] the Case Owner may optionally…" 3. Branch6 updated: "at [step 3] the Case Owner may optionally…" 4. SR1 updated: Branch4 removed Internal updated: 1. Branch5 removed. (Branch2 duplicate), as well as the related branches: Branch23, Branch30 v0.8.0 11/11/2016 Cristina Ezaru Incorporated review received from AHG: 1. Minor formatting and grammar changes 2. Branch1, Branch2, Branch6- last step updated: "The use case ends here" 3. Branch14 removed 4. Branch 15, Branch16 updated: added conditions relating to Branch1, Branch2, Branch6 5. Branch 17, Branch18 updated: steps 2-3 removed 6. Branch34 moved to Branch20 7. updated Sub-process table: AD_BUC_04 Not used 8. BPMN updated Incorporated review received from AC: 1. Branch32 updated: replaced [Step 3] with [Step 4] 2. Minor formatting and grammar changes v0.8.1 17/11/2016 Cristina Ezaru Incorporated review received from AHG: 1. Branch2 updated: added " Only the contact institution is allowed to send P7000" v0.99.0 17/11/2016 Cristina Ezaru Candidate for AC Approval v1.0.0 14/12/2016 Cristina Ezaru AC Approved version v1.0.1 26/06/2017 Madalina Alecsandrescu Latest version of BPMN on section 5 v1.0.2 11/08/2017 Eric Briffoz -Included the version of the BPMN diagram used in section 5.

Correction in the horizontal sub process table in 4.5
Removed Use Case diagram Madalina Alecsandrescu Align wording for Invalidate SED and Forward participant v4.1.0 03/08/2018 Madalina Alecsandrescu
Section 4.4 merged 2 tables (for SED & for Subprocesses) into 1 BUC Artefact table."
Version adaptations to release 4.1.0.
Corrections wording in SR, add exception in SR for [Branch 16]

1 Introduction

1.1 Purpose

The purpose of this document is to construct an external view/part of the 'EESSI business system' as described in EC Regulations 883/2004 and 987/2009. The ‘EESSI Business System’ describes the business and expected business processes without consideration as to which part(s) may be realised by an IT System (i.e. the proposed EESSI IT System). The external view comprises of models and descriptions of business use cases and the services of a business system offered to business actors: customers, business partners or other business systems. A business use case is described from an actor's perspective; it describes the interaction between an actor and the business system, meaning it describes the behaviours of the business system that the actor utilizes. The Business Use Case includes Use Case Diagrams and Business Process Models. Use case diagrams show actors, business use cases and their relationships. Use case diagrams do not describe procedures. Alternative scenarios also remain hidden. These diagrams give a good overview of the behaviours of the EESSI business system which will direct and govern part of the expected behaviours and functionality delivered by the EESSI IT System.

1.2 Scope

This document is limited to the external view on the pension sector process of the Notification of Pension Information. The different elements like use case description, actors, and business process as well as supporting UML diagrams and BPMN models pertaining to the Notification of Pension Information.

1.3 Definitions, Acronyms and Abbreviations

Please see the EESSI Project Glossary here

1.4 References

# Description EC Regulation 883/2004 Regulation EC No 883- 2004.pdf EC Regulation 987/2009 Regulation EC No 987-2009.pdf UML 2.x http://www.omg.org/spec/UML/ BPMN 2.0 http://www.omg.org/spec/BPMN/index.htm UML 2.0 In Action Henriette Baumann, Patrick Grassle & Philippe Baumann, 2005, ISBN 1904811558 RUP@EC standard 5.0 http://www.cc.cec/RUPatEC_Standard/ RUP op maat http://www.rupopmaat.nl/

1.5 Overview

Chapter 1 introduces the external view on the business system under review and lists the elements of this specification. Chapter 2 introduces us to the Notification of Pension Information business process. The chapter gives a short and detailed description as well as a reference to business process´ legal base. Chapter 3 lists the actors involved in the Notification of Pension Information business process. Chapter 4 describes in detail the Notification of Pension Information business process based on the RUP use case template, as well as the relationship to other use cases. Chapter 5 describes the Notification of Pension Information business process using business process modelling notation (BPMN). 2. Description

2.1 Business Scenario

At any time outside the pension claim process changes may occur in one Member State that may result in changes in another Member State. Example of such changes may include (but not exhaustive):

A change/update to the Insurance Periods/Residence in a Member State
A change/update to the Amount of Pension being paid in each Member State
A change/update to the circumstances of the Insured Person, Claimant
A change/update to the Decision in a Member State In such circumstances the Member State where the change occurred must inform other relevant Member States (e.g. Member States where the citizen has also previously lived and worked) of the change.

2.2 Legal Base

This Business Use Case document's legal base is described in the following Regulations

basic Regulation (EC) No 883/2004
implementing Regulation (EC) No 987/2009 The following matrix specifies the SEDs that are used in this Business Use Case and documents the articles that provide the legal basis for each SED. SED Basic Reg (883/04) Implementing Reg (987/09) 12(1) 45(4) 46(1) 46(3) 47(1) 47(4) 47(5) 47(6) 48(1) 48(2) 50(1) 51(2) 52(1)b P5000 P6000 P7000 P10000 Table 1: SED – Legal base relationship matrix 3. Actors & Roles This chapter captures details of the actors which are important to understand the different types of system users. An actor is anyone or anything that exchanges data with the business system. An actor can be a user, external hardware, or another system. The overarching description of each actor described in this Business Use Case can be found in the Glossary. Below you will find a short description which provides further clarity of this actor within the context of this Business Use Case. Actor name Description Case Owner In this BUC the Case Owner is a Competent Institution who needs to inform another institution(s) of a change of the citizen’s insurance record, decision etc. Counterparty In this BUC the Counterparty(ies) is/are the Competent Institution(s) that receives the information sent by the case owner. 4. Use Case

4.1 RUP Table Representation

Use Case ID: P_BUC_06 Use Case Name: Notification of Pension Information Created By: Phil Cummings Last Updated By: Cristina Ezaru Date Created: 19/03/2015 Last Revision Date: 17/11/2016 Actors: Case Owner Counterparty Description: At any time outside the pension claim process changes may occur in one Member State that may result in changes in another Member State. An example of such changes would be (but not exhaustive):

A change/update to the Insurance/Residence Periods in a Member State
A change/update to the Amount of Pension being paid in each Member State
A change/update to the circumstances of the Insured Person, Claimant
A change/update to the Decision in a Member State In such circumstances the Member State where the change occurred must inform other relevant Member States (e.g. Member States where the citizen has also previously lived and worked) of the change. Trigger: An institution needs to inform another institution(s) of a change of the citizen’s insurance record, decision, amount of pension, etc Preconditions: There is a need to inform one or more institution(s). Post conditions: The Case Owner has informed the Counterparties of the new information Main Scenario: Identify Participants 1. The Case Owner identifies the Member State(s) that needs to be informed about changes; 2. The Case Owner then identifies the correct institution(s) (the Counterparty(ies)) in each Member State which must be notified about the changes. There will be one Counterparty or more. The Case Owner and the Counterparty(ies) are herein collectively referred to as the Participants. Send Pension Information 3. The Case Owner fills in a Report on Insurance/Residence Periods (P5000) which provides a detailed summary of the citizen’s insurance periods in their Member State; 4. The Case Owner sends the P5000 to all counterparties of the case. Receive Pension Information 5. Each Counterparty receives the P5000; 6. The use case ends here. Alternative Scenarios: Branch 1:. at [step 3] the Case Owner may choose to fill in and send a Pension Decision. 1. The Case Owner fills in a Pension Decision (P6000) by entering all the required information about the Pension decision they have made; 2. The Case Owner sends the P6000 to all participants of the case; 3. Each Counterparty receives the P6000; 4. The use case ends here.

Branch 2:. at [step 3] the Case Owner may choose to fill in and send a Summary of Pension Decisions. Only the contact institution is allowed to send P7000. 1. The Case Owner fills in a Summary of Pension Decisions (P7000) which provides a detailed summary of the citizen’s pension decision; 2. The Case Owner sends the P7000 to all participants of the case; 3. Each Counterparty receives the P7000; 4. The use case ends here. Branch 3:. [Removed] Branch 4:. [Removed] Branch 5:. [Removed] Branch 6:. at [step 3] the Case Owner may choose to fill in a Transfer of Additional Information. 1. The Case Owner fills in a Transfer of Additional Information (P10000) which details the additional information they wish to transfer; 2. The Case Owner sends the P10000 to all participants of the case; 3. The use case ends here. The Following Branches Determine the use of Horizontally Defined Sub Processes within this Business Process Branch 7:. [Removed] Branch 8:. [Removed] Branch 9:. [Removed] Branch 10:. [Removed] Branch 11:. [Removed] Branch 12:. [Removed] Branch 13:. [Removed] The Following Branches Determine the use of Administrative Sub Processes within this Business Process Branch 14:. [Removed] Branch 15:. at any step after [step 4] or after [Branch 1 step 2] or after [Branch 2 Step 2] or after [Branch 6 Step 2] any participant may choose to Add new participants to this Business Process. Case owner should be able to add participants in any MS, Counterparties should be able to add participants in their own MS. 1. The Participant executes business use case AD_BUC_03_Subprocess – Add Participant; 2. [This Branch] Ends. Branch 16:. at any step after [step 4] or after [Branch 1 step 2] or after [Branch 2 Step 2] or after [Branch 6 Step 2] any participant may choose to Forward this Business Process to another Competent Institution within their MS who assumes responsibility for handling it. 1. The participant executes business use case AD_BUC_05_Subprocess – Forward Case; 2. [This Branch] Ends Branch 17:. where [Step 4] has been executed then at any step after [step 4] the Case Owner may choose to advise all recipients of their P5000 that it is Invalid under Art 5 of 987/09. 1. The Case Owner executes business use case AD_BUC_06_Subprocess - Invalidate_SED; 2. Optionally, the Case Owner fills in P5000, by entering all the required data;

3. Optionally, the Case Owner sends the P5000, including any attachments, to all counterparties; 4. [This Branch] Ends. Branch 18:. where [Branch 1 Step 2] has been executed then at any step after [Branch 1 step 2] the Case Owner may choose to advise all recipients of their P6000 that it is Invalid under Art 5 of 987/09. 1. The Case Owner executes business use case AD_BUC_06_Subprocess - Invalidate_SED; 2. Optionally, the Case Owner fills in P6000, by entering all the required data; 3. Optionally, the Case Owner sends the P6000, including any attachments, to all counterparties; 4. [This Branch] Ends. Branch 19:. where [Branch 2 Step 2] has been executed then at any step after [Branch 2 Step 2] the Case Owner may choose to advise all recipients of their P7000 that it is Invalid under Art 5 of 987/09. 1. The Case Owner executes business use case AD_BUC_06_Subprocess - Invalidate_SED; 2. Optionally, the Case Owner fills in the P7000, by entering all the required data; 3. Optionally, the Case Owner sends the P7000, including any attachments, to all counterparties; 4. [This Branch] Ends. Branch 20:. where [Branch 6 Step 2] has been executed then at any step after [Branch 6 Step 2] the Case Owner may choose to advise all recipients of their P10000 that it is Invalid under Art 5 of 987/09. 1. The Case Owner executes business use case AD_BUC_06_Subprocess - Invalidate_SED; 2. Optionally, the Case Owner fills in P10000, by entering all the required data; 3. Optionally, the Case Owner sends the P10000, including any attachments, to all counterparties; 4. [This Branch] Ends. Branch 21:. [Removed] Branch 22:. [Removed] Branch 23:. [Removed] Branch 24:. [Removed] Branch 25:. where [Branch 1 Step 2] has been executed then at any step after [Branch 1 Step 2] the Case Owner may choose to send an updated version of their P6000. 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends. Branch 26:. where [Branch 2 Step 2] has been executed then at any step after [Branch 2 Step 2] the Case Owner may choose to send an updated version of their P7000. 3. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 4. [This Branch] Ends. Branch 27:. [Removed] Branch 28:. [Removed] Branch 29:. [Removed] Branch 30:. [Removed] Branch 31:. [Removed]

Branch 32:. where [Step 4] has been executed then at any step after [Step 4] the Case Owner may choose to send an updated version of their P5000. 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends. Branch 33:. where [Branch 6 Step 2] has been executed then at any step after [Branch 6 Step 2] the Case Owner may choose to send an updated version of their P10000. 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends. Branch 34:. [Moved in Branch20] Exceptions: Exception 1: [Removed] Includes: See diagram at part 4.4 Special Requirements: SR1: Rules about the invoking of Branches: [Branch 1] – May be invoked once, per Participant [Branch 2] – May be invoked once, per Participant [Branch 6] – May be invoked once, per Participant Administrative [Branch 15] to [Branch 33] – May be invoked more than once, per Participant, exception [Branch 16] – May be invoked only once, per Participant. SR2: Rules about the destination for each SED Type when the SED is sent: P5000 – [May Define and] must be Sent to all Active Participants P6000 - [May Define and] must be Sent to all Active Participants P7000 - [May Define and] must be Sent to all Active Participants P10000 - [May Define and] must be Sent to all Active Participants SR3: The term "Send/Sent to All Active Participants" does not include sending to themselves (i.e. to the senders institution) SR4: Active Participants are defined as those participants identified at [Step 2] and those participants added through the execution of [Branch 15] and/or [Branch 16] and not removed through the execution of [Branch 16] SR5: Alternative Branches 1 – 33 are non-interrupting Branches; Assumptions: Notes and Issues:

4.2 Request – Reply SEDs

The following table specifies the SEDs that have a logical pairing to one another, usually this is known as a request-reply pair. REQUEST SED REPLY SED(s)

4.3 Attachments Allowed

The following table specifies whether attachments are permitted to be included when sending a SED type. SED Attachments P5000 Not Allowed P6000 Allowed P7000 Not Allowed P10000 Allowed

4.4 Artefacts used

The following table specifies the artefacts that are used in this Business Use Case. Artefact name Artefact type P5000 SED P6000 SED P7000 SED P10000 SED AD_BUC_03_Subprocess – Add Participant BUC AD_BUC_05_Subprocess – Forward Case BUC AD_BUC_06_Subprocess – Invalidate SED BUC AD_BUC_10_Subprocess – Update SED BUC AD_BUC_11_Subprocess – Business Exception BUC AD_BUC_12_Subprocess – Change of Participant BUC 5. Business Processes This chapter describes the Business Use Case Notification of Pension Information.