Citation

Source: sozialversicherungen.admin.ch

P_BUC_01_Mainproc_Specification_v4.1.0

EESSI Business Use CaseEESSI Business Use Case EESSI Business Use Case EESSI Business Use Case P_BUC_01 Old Age Pension ClaimP_BUC_01 Old Age Pension Claim P_BUC_01 Old Age Pension Claim P_BUC_01 Old Age Pension Claim Table of Contents Table of Contents 2 Document Control Information Settings Value Document Title: Business Use Case P_BUC_01 - Old Age Pension Claim 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. Changes to this document are summarized in the following table in reverse chronological order (latest version first). Revision Date Created by Short Description of Changes v0.11 28/02/14 Phil Cummings Clarification of Main Scenario Step 11. Additional Information added to Main Scenario step 14. Branch 4 Step 4 Corrected v0.12 05/03/14 Phil Cummings Alt Branches 35 to 37 corrected to allow sending up to Step 15 of Main Scenario Step 15 now includes trigger to Close BUC SR3: P9000 Clarified v0.13 06/03/14 Phil Cummings SR2: Branches 3 – 13 clarified to say "per participant" v0.14 25/03/14 Phil Cummings Re-order the sending of the P1 to precede the P7000 and adjustment of steps to branches to align with this change. Reworded SR2 – to allow the re-execution of some branches where the corresponding SED was cancelled. Minor textual alterations. Alt Branches 8, 25, 36 and 37 marked as - Removed – Models updated to reflect changes Part 6.4 removed as per EB request. v0.15 27/03/14 Phil Cummings Aligned Admin process steps to enable Invalidate and update steps to happen to the same point. Updated branch 26 to prevent P2000 being updated after the issue a P6000 Update to branch 16 (Forward Admin process) to allow for any participant to do it v0.16 20/05/14 Phil Cummings Update following feedback from DG EMPL Testing Team. 1. Case Owner terminology used throughout 2. Correction to Branches 17 and 18 to check for another valid P6000 before rolling back the main process.

3. Branch 19 step 2 altered to read "Revert to Step 13" 4. Clarification added to Branches 26 & 27 to read " for that P6000 instance" 5. Exception amended to include Step 15. 6. Alteration to allow P8000, P9000. P10000 and Horizontals to be exchanged upto Step 15. v0.17 06/03/15 Phil Cummings Incorporated feedback received from AHG, key alterations made: 1. P5000 Steps moved to main scenario 2. Horizontal BUCs removed except Med Report 3. Removed Branches deleted (except 3) 4. Document Re-numbered 5. Close, Reopen, Clarify, Reject Admin steps removed 6. Steps with a previous 'end' to tie in with process closure now open ended. 7. Adjustment to state that Pensioner only needs to claim Pension – not necessarily entitled to the benefit. 8. Included Branches to allow Invalidate of P2000 and P10000. Update of P10000. 9. Business Rules sections removed, and out of date models removed. 10. Legal Basis updated. 11. H_BUC_04 and H_BUC_07 re-added. 12. P6000 rule adjusted to specify one per MS and SR7 added to clarify this. v0.18 30/03/2015 Phil Cummings Enable the sending of another P2000 in the event that P2000 is declared Invalid Enable the sending of another P5000 and P6000 v0.99.0 20/11/2015 Phil Cummings Candidate for AHG Approval Inclusion of Request-Reply Table Inclusion of Attachment Allowed Table Inclusion of SED & Sub-process Versioning Information v0.99.1 26/11/2015 Phil Cummings Minor textual changes following review by Rapporteur. Inclusion of SR8 v0.99.2 27/11/2015 Phil Cummings Update to models v1.0.0 05/01/2016 Phil Cummings AC APPROVED VERSION v1.0.1 26/06/2017 Madalina Alecsandrescu Last version of BPMN – section 5 v1.0.2 11/08/2017 Eric Briffoz

  • Added the version of the BPMN diagram in section 5.

  • Correction in Horizontal sub process table.

  • Inserted reference to BUC confluence page in Configuration Management

  • removed Use Case diagram v1.0.3 19/10/2017 Madalina Alecsandrescu

  • Requested by AhG (no trace of CR, treated as a bug) – Add Participant sub process to CP – Branch 15 – (any participant (Case Owner and Counterparty) may choose to Add participant)

  • BPMN changed, added sub process 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.

- Add SR regarding [Branch 9], [Branch 12], clarifications on branches

1 Introduction

Purpose The purpose of this document is to construct an external view of, 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 realized by an IT System (i.e. the proposed EESSI IT System). The external view comprises of models and descriptions of business use cases, 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. Scope This document is limited to the external view on the pension sector process of the Old Age Pension Claim. The different elements like use case description, actors, and business process as well as supporting UML diagrams and BPMN models pertaining to the Old Age Pension Claim. Definitions, Acronyms and Abbreviations Please see the EESSI Project Glossary here 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/ 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 Old Age Pension Claim 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 Old Age Pension Claim business process.

Chapter 4 describes in detail the Old Age Pension Claim business process based on the RUP use case template, as well as the relationship to other use cases. Chapter 5 describes the Old Age Pension Claim business process using business process modelling notation (BPMN). 2. Description Business Scenario In a situation where a citizen has lived or worked in more than one EU Member State and approaches/reaches Old-Age Pension Age in a Member State a specific institution assumes responsibility for coordinating the citizens pension claim (this is usually the place where citizen resides provided they have paid insurance there, if not other rules apply see 987/09 Art.47.1). This institution assumes the role of the Contact Institution (Case Owner) and is responsible for starting and coordinating a process which assures that the Claimant receives the Old Age Pension benefits they are entitled to and are not disadvantaged by their decision to exercise their right to free movement and work or live in more than one EU Member State (a fundamental pillar of the EU). 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. 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 P2000 P3000 P4000 P5000 P6000 P7000 P8000 P9000 P10000 Table 1: SED – Legal base relationship matrix 3. Actors & Roles This chapter captures details of the actors which are important to understanding 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 performs the role of the Contact Institution as described by the Regulations Counterparty

In this BUC the Counterparty(ies) are Competent Institutions who performs the role of Institutions Concerned as described by the Regulations Claimant In this BUC the Claimant is the Person who wishes to claim an Old Age Pension (i.e. they are a Pensioner) 4. Use Case RUP Table Representation Use Case ID: P_BUC_01 Use Case Name: Old Age Pension Claim Created By: Reginald Amade Last Updated By: Phil Cummings Date Created: 12/08/2013 Last Revision Date: 08/04/2014 Actors: Claimant Case Owner Counterparty Description: In a situation where a citizen has lived or worked in more than one EU Member State and approaches/reaches Old-Age Pension Age in a Member State a specific institution assumes responsibility for coordinating the citizens pension claim (this is usually the place where citizen resides provided they have paid insurance there, if not other rules apply see 987/09 Art.47.1). This institution assumes the role of the Contact Institution (Case Owner) and is responsible for starting and coordinating a process which assures that the Claimant receives the Old Age Pension benefits they are entitled to and are not disadvantaged by their decision to exercise their right to free movement and work or live in more than one EU Member State (a fundamental pillar of the EU). Trigger: A citizen claims an Old Age Pension from one or more EU Member States Preconditions: The Claimant claims an Old Age Pension Post conditions: The Claimant is informed of the decisions made in respect to their Old Age Pension Claim from every Member State that is concerned. Main Scenario: Identify Participants 1. The Case Owner identifies the Member States where the person has lived or worked previously and wishes to claim, or defer, an old-age pension; 2. The Case Owner then identifies the correct institution or institutions (the Counterparty(ies)) in each Member State that are responsible for making a decision on the claim for old-age pension. There will be one counterparty or more. The Case Owner and the Counterparty(ies) are herein collectively referred to as the Participants; Send Old Age Pension Claim 3. The Case Owner fills in an Old Age Pension Claim (P2000) by entering all the required Old-Age Pension data; 4. The Case Owner sends the P2000, including any attachments, to all Counterparties; Process Claim & Send Decision

5. Each Counterparty will receive an Old Age Pension Claim (P2000) with the fitting personal ID dataset and any and all attachments, after which their Claim investigation will start; 6. The Case Owner then optionally fills in a Report on Insurance and Residence Periods (P5000) which provides detailed insurance information to assist the old-age pension processing; 7. The Case Owner sends the P5000 to all other Participants; [Steps 6 and 7] collectively may optionally be repeated by the Case Owner many times after this step 8. The Case Owner fills in an Pension Decision (P6000) by entering all the required information about the Pension decision they have made; 9. The Case Owner sends the P6000 to all counterparties; [Steps 8 and 9] collectively may optionally be repeated by the Case Owner many times after this step 10. Each Counterparty then optionally fills in a Report on Insurance and Residence Periods (P5000) which provides detailed insurance information to assist the old-age pension processing; 11. Each Counterparty then sends the P5000 to all other Participants; [Steps 10 and 11] collectively may optionally be repeated by each Counterparty many times after this step 12. Each Counterparty fills in a Pension Decision (P6000) by entering all the required information about the Pension decision they have made; 13. Each Counterparty then sends their P6000 to the Case Owner and any other Counterparties; [Steps 12 and 13] collectively may optionally be repeated by each Counterparty many times after this step 14. [Steps 6 and 7] collectively, [Steps 8 and 9] collectively, [Steps 10 and 11] collectively and [Steps 12 and 13] collectively may occur in any order Receive & Process Pension Decisions 15. Each time the Case Owner receives a Pension Decision (P6000) from a Counterparty, or it sends a P6000, it checks if: - There is at least one valid P6000 or other equivalent information, that the case can be closed from each participant involved If this is true the Case Owner, OR at the discretion of the Case Owner continues to the [Next Step] if not it repeats [This Step]; Finalize Claim for Old Age Pension

16. The Case Owner fills in a Portable Document (P1) by entering specific data provided in the Pension Decisions (P6000) exchanged by all participants. The completed P1 is then sent to the claimant to inform them of the Pensions decisions taken by all participants and their right to review; 17. The Case Owner fills in a Summary of Pension Decisions (P7000) by entering specific data provided in the Pension Decisions (P6000) exchanged by all participants; 18. The Case Owner sends the P7000 to all Counterparties 19. Upon the sending of the P7000 the Old Age Pension Claim is complete Alternative Scenarios: Branch 1:. at any step after [step 5] the Case Owner may optionally choose to fill in and send Country Specific Information 1. The Case Owner fills in Country Specific Information (P3000_XX) which provides supplementary information to assist the old-age pension processing in the Member State it was designed for; 2. The Case Owner sends the P3000_xx to specific counterparties (see Special Requirements) 3. [This Branch] Ends Branch 2:. at any step after [step 5] the Case Owner may optionally choose to fill in and send a Report on Insurance History 1. The Case Owner fills in Report on Insurance History (P4000) which provides supplementary information to assist the old-age pension processing; 2. The Case Owner sends the P4000 to all Counterparties 3. [This Branch] Ends Branch 3:. [Removed] Branch 4:. at any step after [step 5] any Participant may optionally choose to fill in a Request for Additional Information 1. The Participant who invokes this branch fills in a Request for Additional Information (P8000) which details the additional information they need; 2. The Participant who wishes to request additional information sends the P8000 to one or more participants (the receiving participants are at the discretion of the sending participant) 3. Each Participant who received a P8000 may optionally gather the requested information and fill in a Reply to Request for Additional Information (P9000) provided the P8000 is not declared to be invalid at [invoking Branch 25]; 4. Where [Branch 4 Step 3] was completed each Participant who filled out the P9000 sends the P9000, including any attachments, to the sender of the P8000 and all other Participants who received the P8000.

5. Upon receipt of a P9000 the Participant may optionally choose to send another P8000 provided the P9000 is not declared to be invalid at [invoking Branch 26]; [go to Branch 4 Step 1] 6. [This Branch] Ends Branch 5:. at any step after [step 5] any Participant may optionally choose to fill in a Transfer of Additional Information 1. The Participant who invokes this branch fills in a Transfer of Additional Information (P10000) which details the additional information they wish to transfer; 2. The Participant who wishes transfer the additional information sends the P10000, with any attachments, to one or more Participants (the receiving participants are at the discretion of the sending participant) 3. [This Branch] Ends The Following Branches determine the use of Horizontally Defined Sub Processes within this Business Process

  • Removed -

  • Removed -

  • Removed - Branch 9:. at any step after [step 5] any Participant may optionally choose to request the Reimbursement of Admin Costs or Medical Costs from another Participant 1. The Participant executes business use case H_BUC_04_Subprocess – Reimbursement of Admin or Medical Costs; 2. [This Branch] Ends

  • Removed -

  • Removed - Branch 12:. at any step after [step 5] any Participant may optionally choose notify another Participant of the Death of a Person 1. The Participant executes business use case H_BUC_07_Subprocess – Notification of Death; 2. [This Branch] Ends Branch 13:. at any step after [step 5] any Participant may optionally choose to Request and Exchange Medical Data with another Participant 1. The Participant executes business use case H_BUC_08_Subprocess – Exchange of Medical Data; 2. [This Branch] Ends The Following Branches Determine the use of Administrative Sub Processes within this Business Process Branch 14:. at any step after [step 5] the Case Owner may choose to Remove a Counterparty from this Business Process 1. The Case Owner executes business use case AD_BUC_04_Subprocess – Remove Participant; 2. [This Branch] Ends Branch 15:. at any step after [step 5] any Participant may choose to Add a Counterparty to this Business Process 1. Any Participants executes business use case AD_BUC_03_Subprocess – Add Participant; 2. [This Branch] Ends

Branch 16:. at any step after [step 5] 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:. at any step after [step 5] the Case Owner may choose to advise all recipients of their P2000 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 an Old Age Pension Claim (P2000) by entering all the required Old-Age Pension data; 3. Optionally, the Case Owner sends the P2000, including any attachments, to all Counterparties; 4. [This Branch] Ends Branch 18:. at any step after [step 7] 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 an Old Age Pension Claim (P5000) by entering all the required Old-Age Pension data; 3. Optionally, the Case Owner sends the P5000, including any attachments, to all Counterparties; 4. [This Branch] Ends Branch 19:. at any step after [step 11] a Counterparty may choose to advise all recipients of their P5000 that it is Invalid under Art 5 of 987/09 1. The Counterparty executes business use case AD_BUC_06_Subprocess - Invalidate_SED; 2. Optionally, the Counterparty fills in an Old Age Pension Claim (P5000) by entering all the required Old-Age Pension data; 3. Optionally , the Counterparty sends the P5000, including any attachments, to all Counterparties; 4. [This Branch] Ends Branch 20:. at any step after [step 9] 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. If no other Valid P6000 exists from the Case Owner then the Main Scenario reverts to [step 8]. 3. [This Branch] Ends Branch 21:. at any step after [step 13] a Counterparty may choose to advise all recipients of their P6000 that it is Invalid under Art 5 of 987/09 1. The Counterparty executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

2. If no other Valid P6000 exists for this Counterparty then the Main Scenario reverts to [step 8]. 3. [This Branch] Ends Branch 22:. at any step after [step 18] , 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. The Main Scenario reverts to [step 16]. 3. [This Branch] Ends. Branch 23:. 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 P3000_xx 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 an Old Age Pension Claim (P3000_xx) by entering all the required Old-Age Pension data; 3. Optionally , the Case Owner sends the P3000_xx, including any attachments, to all Counterparties; 4. [This Branch] Ends Branch 24:. 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 P4000 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 an Old Age Pension Claim (P4000) by entering all the required Old-Age Pension data; 3. Optionally, the Case Owner sends the P4000, including any attachments, to all Counterparties; 4. [This Branch] Ends Branch 25:. where [Branch 4 Step 2] has been executed then at any step after [Branch 4 Step 2] the Participant who sent the P8000 may choose to advise all recipients of their P8000 that it is Invalid under Art 5 of 987/09 1. The Participant executes business use case AD_BUC_06_Subprocess - Invalidate_SED; 2. Optionally, the Participant fills in an Old Age Pension Claim (P8000) by entering all the required Old-Age Pension data; 3. Optionally, the Participant sends the P8000, including any attachments, to all participants; 4. [This Branch] Ends Branch 26:. where [Branch 4 Step 4] has been executed then at any step after [Branch 4 Step 4] the participant who sent the P9000 may choose to advise all recipients of their P9000 that it is Invalid under Art 5 of 987/09 1. The Participant executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

2. Optionally, the Participant fills in an Old Age Pension Claim (P9000) by entering all the required Old-Age Pension data; 3. Optionally, the Participant sends the P9000, including any attachments, to all Participants; 4. [This Branch] Ends Branch 27:. where [Branch 5 Step 2] has been executed then at any step after [Branch 5 Step 2] the Participant who sent the P10000 may choose to advise all recipients of their P10000 that it is Invalid under Art 5 of 987/09 1. The Participant executes business use case AD_BUC_06_Subprocess - Invalidate_SED; 2. Optionally , the Participant fills in an Old Age Pension Claim (P10000) by entering all the required Old-Age Pension data; 3. Optionally, the Participant send the P10000, including any attachments, to all participants; 5. [This Branch] Ends Branch 28:. at any step after [step 5] the Case Owner may choose to send an updated version of P2000 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 29:. at any step after [step 7] 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 30:. at any step after [step 11] a counterparty may choose to send an updated version of their P5000 1. The Counterparty executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 31:. at any step after [step 9] 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 32:. at any step after [step 9] a Counterparty may choose to send an updated version of their P6000 1. The Counterparty executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 33:. at any step after [step 18] the Case Owner may choose to send an updated version of their P7000 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 34:. 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 P3000_xx 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED: 2. [This Branch] Ends

Branch 35:. 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 P4000 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 36:. where [Branch 4 Step 2] has been executed then at any step after [Branch 4 Step 2] the participant who sent the P8000 may choose to send an updated version of their P8000 1. The Participant executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 37:. where [Branch 4 Step 4] has been executed then at any step after [Branch 4 Step 4] the participant who sent the P9000 may choose to send an updated version of their P9000 1. The Participant executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 38:. where [Branch 5 Step 2] has been executed then at any step after [Branch 5 Step 2] the participant who sent the P10000 may choose to send an updated version of their P10000 3. The Participant executes business use case AD_BUC_10_Subprocess - Update_SED; 4. [This Branch] Ends Branch 39:. at any step after [step 5] and any Participant may optionally choose to send a Reminder to another Participant for the return of information they were expecting from that participant but did not receive. 1. The participant who invokes this branch executes business use case AD_BUC_07_Subprocess -_Reminder; 2. [This Branch] Ends Exceptions: Exception 1: [Removed] Includes: See diagram at part 4.2 Frequency of Use: This BUC is expected be to executed [tbd] times per year. Special Requirements: SR1: When Alternative [Branch 1] is invoked the Country Specific Information (P3000_XX) can only be sent to institutions in the MS it was designed for. This is identifiable by the last two characters of the P3000_XX – represented here as "XX" for example: P3000_UK can only be sent to institutions in the UK P3000_DE can only be sent to institutions in Germany SR2: Rules about the invoking of Branches: [Branch 1] – May only be invoked per Destination Member State (see SR1) when there is no valid P3000_xx [Branch 2] – May only be invoked once, per Participant [Branch 4] – May be invoked more than once, per Participant [Branch 5] – May be invoked more than once, per Participant Horizontals [Branch 9] - May be invoked more than once, per Participant.

[Branch 12] - May be invoked only once, per Participant. [Branch 13] - May be invoked more than once, per Participant Administrative [Branch 14] to [Branch 39] – May be invoked more than once, per Participant, exception [Branch 16] – May be invoked only once, per Participant. SR3: Rules about the destination for each SED Type when the SED is sent: P2000 – Defines and is sent to all Active Participants P3000_xx – Must be Sent to All Active Participants of the MS designed for (See SR1) P4000 – Must be Sent to all Active Participants P5000 - Must be Sent to all Active Participants P6000 - Must be Sent to all Active Participants P7000 - Must be Sent to all Active Participants P8000 – Can be sent to one or more Active Participants P9000 – Must be sent to all Active Participants that received the P8000 P10000 - Can be sent to one or more Active Participants SR4: The term "Send/Sent to All Active Participants" does not include sending it himself (i.e. to the senders institution) SR5: 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 14] and/or [Branch 16] SR6: Alternative Branches 1 – 39 are non-interrupting Branches; SR7: Clarification: where two or more institutions from the same MS are involved in the case only one P6000 needs to be exchanged from that MS to satisfy this rule. SR8: "at the discretion of the Case Owner" – allows under exceptional circumstances for the Case Owner to progress to the next Steps without all P6000 information. Assumptions: Notes and Issues: Request – Reply SEDs The following table specifies the SED that have a logical pairing to one another, usually this is known as a request-reply pair. REQUEST SED REPLY SED(s) P8000 P9000 Attachments Allowed The following table specifies whether attachments are permitted to be included when sending a SED type. SED Attachments P2000 Allowed P3000_XX Allowed P4000 Allowed P5000 Not Allowed P6000 Allowed P7000 Not Allowed P8000 Allowed P9000 Allowed P10000 Allowed

4.1 Artefacts used

The following table specifies the artefacts that are used in this Business Use Case. Artefact name Artefact type P2000 SED P3000_XX SED P4000 SED P5000 SED P6000 SED P7000 SED P8000 SED P9000 SED P10000 SED H_BUC_04_Subprocess BUC H_BUC_07_Subprocess BUC H_BUC_08_Subprocess BUC AD_BUC_03_Subprocess – Add Participant BUC AD_BUC_04_Subprocess – Remove Participant BUC AD_BUC_05_Subprocess – Forward Case BUC AD_BUC_06_Subprocess – Invalidate SED BUC AD_BUC_07_Subprocess – Reminder 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 Old Age Pension Claim. Case Owner Counterparty Sub Processes n/a 6. Appendices Issues # Issue date Description Replies Action/Resolution Close date 10/03/14 Issue referred to B4 for legal view on situation where one or more MS is asked to defer the Pension. Should the provisions of Art 48 wait for the deferment or not? Email to Joanna KACZANOWSKA 18/03/14. Decision: Process should wait for all decisions. 07/04/2014