P_BUC_05_Mainproc_Specification_v4.1.0

Annex Nr.9 to the note AC 370/16revAnnex Nr.9 to the note AC 370/16rev Annex Nr.9 to the note AC 370/16rev Annex Nr.9 to the note AC 370/16rev EESSI Business Use CaseP_BUC_05EESSI Business Use CaseP_BUC_05 EESSI Business Use Case P_BUC_05 EESSI Business Use Case P_BUC_05 Ad-hoc Request for Pension InformationAd-hoc Request for Pension Information Ad-hoc Request for Pension Information Ad-hoc Request for Pension Information Table of Contents Table of Contents 2 Document Control Information Settings Value Document Title: Business Use Case P_BUC_05 - Adhoc Request for 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.01 01/05/15 Phil Cummings First Draft v0.02 20/05/15 Phil Cummings Update following review with AHG. Minor corrections to branches. Removal of P10000 branch. Additional Invalidity Type A only scenario added. v0.03 09/09/2015 Phil Cummings Addition of P7000 and P8000 SED to Counterparty Addition of P4000, P5000, P6000, P7000 and P9000 to Case Owner Added Invalidate and Update. v0.4.0 25/04/2016 Cristina Ezaru Minor corrections/updates in Document Control Information and Purpose. Update the document template with new subchapters 4.2; 4.3; 4.4; 4.5 v0.5.0 16/05/2016 Cristina Ezaru Incorporated feedback received from AHG, key alteration made: 1. correction in Branch5: " Request for Additional Information" instead of the current text 2. Branch20 updated: adding participants should be able to any participant (within their own MS) 3. corrections in Branch 26,35,38,39,40 step 1:the Counterparty executes BUC 4. Branches 17,18 were added to SR2 5. updated Request-Replay SEDs table: only P8000-P9000 are request-reply pairs. 6. updated Attachments Allowed table 7. updated Sub-process table: AD_BUC_11 is used v0.6.0 20/05/2016 Cristina Ezaru Incorporated review received from AHG:

1. Branch 20 updated: Case owner can add participants in any MS, Counterparties can add participants in their own MS. 2. P10000 removed from several references v0.99.0 23/05/2016 Cristina Ezaru Candidate for AC Approval as agreed by the Pension rapporteur. v0.99.1 30/05/2016 Cristina Ezaru Minor formatting, date, version and grammar changes Updated Use Case diagram. v0.99.2 13/06/2016 Cristina Ezaru Use of Consistent terminology for branches 22-35 Correction of SED version: to v4.0.x Inclusion of BPMN v1.0.0 14/07/2016 Phil Cummings AC Approved Version v1.0.1 26/06/2017 Madalina Alecsandrescu Last version BPMN section 5 v1.0.2 11/08/2017 Eric Briffoz

Included the version of the BPMN diagram in section 5.
Correction in horizontal sub process table in section 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.
Correction wording in SR, add exception [Branch 21]

1 Introduction

1.1 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.

1.2 Scope

This document is limited to the external view on the pension sector process of the Adhoc Request for 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 Adhoc Request for Pension Information.

1.3 Definitions, Acronyms and Abbreviations

Please see the EESSI Project Glossary here <<Link>>

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 Adhoc Request for 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 Adhoc Request for Pension Information business process. Chapter 4 describes in detail the Adhoc Request for Pension Information business process based on the RUP use case template, as well as the relationship to other use cases. Chapter 5 describes the Adhoc Request for Pension Information business process using business process modelling notation (BPMN). 2. Description

2.1 Detailed Description

Situations may occur within the processing of ongoing national Pension Cases where there is a need to request information from another Member State to assist with the national processing. Such examples may include, but are not limited to:

A need to recalculate the citizens pension amounts due to a change of circumstances
A need under national legislation to check the particulars of a citizens situation (eg how much pension they are being paid)
Invalidity Pension situation involving only 'Type A' Member States where one MS requires insurance periods.

2.2 Legal Base

This document's legal base is found in the following EC Regulations: 1. basic Regulation (EC) No 883/2004 2. implementing Regulation (EC) No 987/2009 The following matrix derived from version 3 SEDs, documented by the expert AHGs, lists the SEDs used in this Business Use Case and their relation with the articles mentioned above. 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 P4000 P5000 P6000 P7000 P8000 P9000 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 requires the information to continue with the national case processing. Counterparty In this BUC the Counterparty(ies) are Competent Institutions that provide the required information to assist with the national case processing of the Case Owner. Table 2: Actors & Roles 4. Use Case

4.1 RUP Table Representation

Use Case ID: P_BUC_05 Use Case Name: Adhoc Request for Pensions Information Created By: Phil Cummings Last Updated By: Cristina Ezaru Date Created: 01/05/2015 Last Revision Date: 13/06/2016 Actors: Case Owner Counterparty Description: Situations may occur within the processing of ongoing national Pension Cases where there is a need to request information from another Member State to assist with the national processing. Such examples may include, but are not limited to:

A need to recalculate the citizens pension amounts due to a change of circumstances
A need under national legislation to check the particulars of a citizens situation (eg how much pension they are being paid)
Invalidity Pension situations involving only 'Type A' Member States where one MS requires insurance periods. Trigger: An institution requires information as part of their national case processing. Preconditions: none Post conditions: The Case Owner has receives the information they require to process their national case. Main Scenario: Identify Participants 1. The Case Owner identifies the Member State(s) that they require the information from; 2. The Case Owner then identifies the correct institution or institutions (the Counterparty(ies)) in each Member State that are responsible for providing the Pensions Information they need. There will be one Counterparty or more. The Case Owner and the Counterparty(ies) are herein collectively referred to as the Participants; Send Adhoc Request for Pension Information 3. The Case Owner fills in a Request for Additional Information (P8000) which details the additional information they need; 4. The Case Owner sends the P8000 to all participants. Provide Adhoc Pension Information 5. Each participant who received a P8000 may optionally gather the requested information and fill in a Reply to Request for Additional Information (P9000) 6. Each participant who filled out the P9000 sends the P9000, including any attachments, to other participants. 7. Upon sending P8000 the Case Owner may optionally choose to send another P8000; [go to Step 3] This Business Use Case Ends Branch 1:. at any step after [step 4] a Counterparty may optionally choose to fill in and send a Report on Insurance History 1. The Counterparty fills in Report on Insurance History (P4000) which provides information the insurance history of the citizen

2. The Counterparty sends the P4000 to the Case Owner and other Counterparties (if any) 3. [This Branch] Ends Branch 2:. at any step after [step 5] the Counterparty may optionally choose to fill in and send a Report on their Insurance/Residence Periods 1. The Counterparty fills in Report on Insurance/Residence Periods (P5000) which provides a detailed summary of the citizens insurance periods in their Member State; 2. The Counterparty sends the P5000 to the Case Owner and other Counterparties (if any) 3. [This Branch] Ends Branch 3:. at any step after [step 5] the Counterparty may optionally choose to fill in and send a Pension Decision 1. The Counterparty fills in a Pension Decision (P6000) which provides a detailed summary of the citizens pension decision; 2. The Counterparty sends the P6000 to the Case Owner and other Counterparties (if any) 3. [This Branch] Ends Branch 4:. at any step after [step 5] the Counterparty may optionally choose to fill in and send a Summary of Pension Decisions 1. The Counterparty fills in a Summary of Pension Decisions (P7000) which provides a detailed summary of the citizens pension decision; 2. The Counterparty sends the P7000 to the Case Owner and other Counterparties (if any) 3. [This Branch] Ends Branch 5:. at any step after [step 5] the Counterparty may optionally choose to fill in and send a Request for Additional Information 1. The Counterparty fills in a Request for Additional Information (P8000) which details the additional information they need; 2. The Counterparty sends the P8000 to the Case Owner and other Counterparties (if any) 3. [This Branch] Ends Branch 6:. at any step after Branch 5 [step 2] a 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 information the insurance history of the citizen 2. The Case Owner sends the P4000 to the Counterparty(ies) 3. [This Branch] Ends Branch 7:. at any step after Branch 5 [step 2] a Case Owner may optionally choose to fill in and send a Report on their Insurance/Residence Periods 1. The Case Owner fills in Report on Insurance/Residence Periods (P5000) which provides a detailed summary of the citizens insurance periods in their Member State; 2. The Case Owner sends the P5000 to the Counterparty(ies) 3. [This Branch] Ends

Branch 8:. at any step after Branch 5 [step 2] a Case Owner may optionally choose to fill in and send a Pension Decision 1. The Case Owner fills in a Pension Decision (P6000) which provides a detailed summary of the citizens pension decision; 2. The Case Owner sends the P6000 to the Counterparty(ies) 3. [This Branch] Ends Branch 9:. at any step after Branch 5 [step 2] a Case Owner may optionally choose to fill in and send a Summary of Pension Decisions 1. The Case Owner fills in a Summary of Pension Decisions (P7000) which provides a detailed summary of the citizens pension decision; 2. The Case Owner sends the P7000 to the Counterparty(ies) 3. [This Branch] Ends Branch 10:. at any step after Branch 5 [step 2] a Case Owner may optionally choose to fill in a Reply to Request for Additional Information 1. The Case Owner fills in Reply to Request for Additional Information (P9000) 2. The Case Owner sends the P9000 to the Counterparty(ies) 3. [This Branch] Ends The Following Branches determine the use of Horizontally Defined Sub Processes within this Business Process

Removed -
Removed -
Removed -
Removed-
Removed -
Removed - Branch 17:. at any step after [step 4] 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 18:. at any step after [step 4] any participant may optionally choose to provide the Case Owner and other Counterparties (if any) with a detailed Medical Examination 1. The Counterparty executes business use case H_BUC_09 – Notification of a Medical Report; 2. [This Branch] Ends The Following Branches Determine the use of Administrative Sub Processes within this Business Process Branch 19:. at any step after [step 4] 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 20:. at any step after [step 4] any Participant may choose to Add a new participants to this Business Process. 1. The Participant executes business use case AD_BUC_03_Subprocess – Add Participant; 2. [This Branch] Ends

Branch 21:. at any step after [step 4] 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 22:. at any step after [step 4] the Case Owner may choose to advise all recipients of their P8000 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 a Request for Additional Information (P8000) which details the additional information they need; 3. Optionally, the Case Owner sends the P8000 to all participants. 4. [This Branch] Ends Branch 23:. at any step after [step 6] a Counterparty may choose to advise all recipients of their P9000 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 P9000, by entering all the required data; 3. Optionally, the Counterparty sends the P9000, including any attachments, to all counterparties; 4. [This Branch] Ends Branch 24:. where [Branch 1 Step 2] has been executed then at any step after [Branch 1 Step 2] a Counterparty may choose to advise all recipients of their P4000 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 P4000, by entering all the required data; 3. Optionally, the Counterparty sends P4000, including any attachments, to all counterparties; 4. [This Branch] Ends Branch 25:. where [Branch 2 Step 2] has been executed then at any step after [Branch 2 Step 2] 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 P5000, by entering all the required data; 3. Optionally, the Counterparty sends P5000, including any attachments, to all counterparties; 4. [This Branch] Ends Branch 26:. where [Branch 3 Step 2] has been executed then at any step after [Branch 3 Step 2] 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. Optionally, the Counterparty fills in P6000, by entering all the required data; 3. Optionally, the Counterparty sends P6000, including any attachments, to all counterparties; 4. [This Branch] Ends Branch 27:. where [Branch 4 Step 2] has been executed then at any step after [Branch 4 Step 2] a Counterparty may choose to advise all recipients of their P7000 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 P7000, by entering all the required data; 3. Optionally, the Counterparty sends P7000, including any attachments, to all counterparties; 4. [This Branch] Ends. Branch 28:. where [Branch 5 Step 2] has been executed then at any step after [Branch 5 Step 2] a Counterparty may choose to advise all recipients of their P8000 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 P8000, by entering al the required data; 3. Optionally, the Counterparty sends P8000, including any attachments, to all counterparties; 4. [This Branch] Ends Branch 29:. where [Branch 6 Step 2] has been executed then at any step after [Branch 6 Step 2] a 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 P4000, by entering all the required data; 3. Optionally, the Case Owner sends P4000, including any attachments, to all Counterparties; 4. [This Branch] Ends Branch 30:. where [Branch 7 Step 2] has been executed then at any step after [Branch 7 Step 2] a 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 required data; 3. Optionally, the Case Owner sends P5000, including any attachments, to all counterparties; 4. [This Branch] Ends

Branch 31:. where [Branch 8 Step 2] has been executed then at any step after [Branch 8 Step 2] a 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 the 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 32:. where [Branch 9 Step 2] has been executed then at any step after [Branch 9 Step 2] a 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 33:. where [Branch 10 Step 2] has been executed then at any step after [Branch 10 Step 2] a Case Owner may choose to advise all recipients of their P9000 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 P9000, entering all the required data; 3. Optionally, the Case Owner sends the P9000, including any attachments, to all counterparties; 4. [This Branch] Ends Branch 34:. at any step after [step 4] the Case Owner may choose to send an updated version of P8000 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 35:. at any step after [step 6] the Counterparty may choose to send an updated version of their P9000 1. The Counterparty executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 36:. where [Branch 1 Step 2] has been executed then at any step after [Branch 1 Step 2] a Counterparty may choose to send an updated version of their P4000 1. The Counterparty executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 37:. where [Branch 2 Step 2] has been executed then at any step after [Branch 2 Step 2] a Counterparty may choose to send an updated version of their P5000 3. The Counterparty executes business use case AD_BUC_10_Subprocess - Update_SED;

4. [This Branch] Ends Branch 38:. where [Branch 3 Step 2] has been executed then at any step after [Branch 3 Step 2] 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 39:. where [Branch 4 Step 2] has been executed then at any step after [Branch 4 Step 2] a Counterparty may choose to send an updated version of their P7000 1. The Counterparty executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 40:. where [Branch 5 Step 2] has been executed then at any step after [Branch 5 Step 2] a Counterparty may choose to send an updated version of their P8000 1. The Counterparty executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 41:. where [Branch 6 Step 2] has been executed then at any step after [Branch 6 Step 2] a 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 42:. where [Branch 7 Step 2] has been executed then at any step after [Branch 7 Step 2] a 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 43:. where [Branch 8 Step 2] has been executed then at any step after [Branch 8 Step 2] a 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 44:. where [Branch 9 Step 2] has been executed then at any step after [Branch 9 Step 2] a 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 45:. where [Branch 10 Step 2] has been executed then at any step after [Branch 10 Step 2] a Case Owner may choose to send an updated version of their P9000 1. The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED; 2. [This Branch] Ends Branch 46:. at any step after [step 4] 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: Rules about the invoking of Branches: [Branch 1] – May be invoked once, per Participant [Branch 2] – May be invoked once, per Participant [Branch 3] – May be invoked more than once, per Participant [Branch 4] – May be invoked once, per Participant [Branch 5] – May be invoked more than once, per Participant [Branch 6] – May be invoked once, per Participant [Branch 7] – May be invoked once, per Participant [Branch 8] – May be invoked more than once, per Participant [Branch 9] – May be invoked once, per Participant [Branch 10] – May be invoked more than once , per Participant Horizontals [Branch 17] - May be invoked once, per Participant [Branch 18] - May be invoked more than once, per Participant Administrative [Branch 19] to [Branch 46] – May be invoked more than once, per Participant, exception [Branch 21] – May be invoked only once, per Participant. SR2: Rules about the destination for each SED Type when the SED is sent: P8000 – Defines and is sent to all Active Participants P9000 – Must be sent to all Active Participants 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 SR3: The term "Send/Sent to All Active Participants" does not include sending it himself (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 20] and/or [Branch 21] and not removed through the execution of [Branch 19] and/or [Branch 21] SR5: Alternative Branches 1 – 46 are non-interrupting Branches; Assumptions: Notes and Issues:

4.2 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

2.1 Attachments Allowed

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

2.2 Artefacts used

The following table specifies the artefacts that are used in this Business Use Case. Artefact name Artefact type P4000 SED P5000 SED P6000 SED P7000 SED P8000 SED P9000 SED H_BUC_07_Subprocess BUC H_BUC_09_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 2. Business Processes The following paragraphs describe the Business Use Case Adhoc Request for Pension Information.