P_BUC_10_Mainproc_Specification_v4.1.0 | Lexipedia

EESSI Business Use Case

P_BUC_10 Transitional cases

Table of Contents

Table of Contents 2

1. Introduction 7

1.1. Purpose 7

1.2. Scope 7

1.3. Definitions, Acronyms and Abbreviations 7

1.4. References 8

1.5. Overview 8

2. Description 9

2.1. Business Scenario 9

2.2. Legal Base 9

3. Actors & Roles 10

4. Use Case 11

4.1. RUP Table Representation 11

4.2. Request – Reply SEDs 20

4.3. Attachments Allowed 20

4.4. Artefacts used 21

5. Business Processes 22

5.1. Case Owner and Counterparty 22

5.2. Sub Processes 22

6. Appendices 24

6.1. Issues 24

Document Control Information

Settings

Value

Document Title:

Business Use Case

P_BUC_10 - Transitional Cases

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

14/10/2016

Cristina Ezaru

First Draft

v0.2.0

19/12/2016

Cristina Ezaru

Incorporated feedback received from AHG:

1. legal base updated for P15000

2. Preconditions updated

3. Main Scenario- Identify participants updated

4. Actors & Roles updated

5. Trigger updated

6. Post conditions updated

7. Process claim & send decision - step 5 updated

8. Receive & process pension decisions – steps 15, 16, 17, 18 updated –

replaced "Case Owner" by "Participant"

9. Branch2 updated

10. updated references for Branch3 step4-5; Branch 20; Branch 21;

Branch 22; Branch 26; Branch 27; Branch 32; Branch 33; Branch 34.

11. all branches renumbering

12. new Branch added – H_BUC_09 Notification of a medical report

13. Branch9 and Branch10 updated – restriction for adding/removing

participants by CO and CP was removed

14. Branch17, Branch18, Branch19, Branch28, Branch29, Branch30

updated – replaced "Case Owner/ Counterparty" by "Participant"

15. SR7 updated

16. Business Scenario updated

v0.3.0

13/01/2017

Cristina Ezaru

Incorporated feedback received from AHG:

1. Main Scenario step 1 updated

2. "Case Owner", "Counterparty" and "Participant" replaced by "Contact

Institution" in:

- Main Scenario steps 15, 16, 17, 18

- Branches 12, 13, 14, 15, 16, 17, 18, 19, 23, 24, 25, 26, 27, 28, 29, 30

- SR8

3. H_BUCs name updated: Branches 5, 6, 7,

4. Branch 3 updated: steps 3 and 5 – invoking Branch 20/ Branch 21

5. Branch 16 updated: step 2 – "reverts to step 8"

6. Actors&Roles updated: added Contact Institution reference

v0.4.0

20/02/2017

Cristina Ezaru

Incorporated review received during the AHG meeting (15/02/2017):

1. "Contact Institution" replace by "Participant"in:

- Main Scenario 15, 18 (only the receiver)

- Branches 14, 16, 25, 27

2. "Contact Institution" replace by "Case Owner"in:

- Branches 12, 13, 15, 23, 24, 26

3. "Case Owner" replaced by "Contact Institution"in:

- Branches 1, 2

Incorporated feedback received from AC:

1. Legal Base matrix updated – P3000

2. SR2 updated for Branch6, Branch11

3. SR6 updated for Branch11, Branch12

4. Business Scenario Description updated – time limited rephrased

5. Business Scenario Description updated – "Aps" removed

6. Post Conditions updated

7. Trigger updated

8. Header updated

v0.4.1

23/02/2017

Cristina Ezaru

Incorporated feedback received from AHG:

1. Business Scenario Description updated – "Aps" removed

2. Actors&Roles updated for Contact Institution

3. Main Scenario: Send Claim replaced by Send P15000.

4. Trigger updated

v0.99.0

23/02/2017

Cristina Ezaru

Candidate for AC Approval

v 0.99.1

28/06/2017

A Madalina Alecsandrescu

included BPMN last version

v1.0.0

05/07/2017

A Madalina Alecsandrescu

Changed version according D2 and team leader

v1.0.1

08/08/2017

A Madalina Alecsandrescu

Included BPMN last version (added subprocesses)

v1.0.2

11/08/2017

Eric Briffoz

-Included the version of the BUC Diagram used 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.

- Corrections in wording

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 Transitional Cases. The different elements like use case description, actors, and business process as well as supporting UML diagrams and BPMN models pertaining to the Transitional Cases.

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 Transitional cases 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 Transitional cases business process.

Chapter 4 describes in detail the Transitional cases business process based on the RUP use case template, as well as the relationship to other use cases.

Chapter 5 describes the Transitional cases business process using business process modelling notation (BPMN).

Description

Business Scenario

This Business Use Case describes the transition of a pension claim from paper to electronic SEDs for cases started before EESSI is going in production. The use of the BUC is time limited after the end of the transition period.

Such a case, "on-going-case", is one which has started on paper and where the institutions involved have become EESSI enabled before the case is completed.

Definition of an "on-going-case":

At least one initial paper transmission of data has taken place between institutions in two or more Member States, and

At least one further exchange is expected before the case becomes resolved, and

The institutions involved have, subsequent to the initial paper exchange(s), become EESSI enabled. This may have occurred during the Transitional Period itself or at the point when the Transitional Period ends.

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)

51(2)

52(1)b

AC E1

P3000

P4000

P5000

P6000

P7000

P8000

P9000

P10000

P15000

Table 1: SED – Legal base relationship matrix

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 the participant that needs to send the next SED in the claim procedure that has started on paper and after all participants have become EESSI enabled. It can be the Contact Institution or any other participant involved in the claim procedure.

Counterparty

In this BUC the Counterparties are the other participants that are involved in the claim procedure. Even the actual Contact Institution can be a Counterparty in a transitional case.

Claimant

In this BUC the Claimant is the Person who claimed one of the following claim types: Old Age Pension, Survivors Pensions or Invalidity Pension.

Contact Institution

In this BUC the Contact Institution (as described by the Regulations) can perform the role of the Case Owner or the Counterparty.

Use Case

RUP Table Representation

Use Case ID:

P_BUC_10

Use Case Name:

Transitional cases

Created By:

Cristina Ezaru

Last Updated By:

Cristina Ezaru

Date Created:

14/10/2016

Last Revision Date:

23/02/2017

Actors:

Case Owner

Counterparty

Claimant

Contact Institution

Description:

Such a case, "on-going-case", is one which has started on paper and where the institutions involved have become EESSI enabled before the case is completed.

Definition of an "on-going-case":

At least one initial paper transmission of data has taken place between institutions in two or more Member States, and

At least one further exchange is expected before the case becomes resolved, and

Trigger:

The institutions involved have, subsequent to the initial paper exchange(s), become EESSI enabled and the Case Owner (can be Contact Institution or any Participant in the claim procedure) needs to send the following SED.

Preconditions:

An initial pension claim (P_BUC_01 Old Age pension, P_BUC_02 Survivor pension or P_BUC_03 Invalidity pension) had been made on paper or in other form outside EESSI.

Post conditions:

The claim procedure is finalized in EESSI and the Claimant is informed of the decisions made in respect to their Pension Claim from each Member States.

Main Scenario:

Identify Participants

The Case Owner identifies a case in which a request has been made or a claim has been started on paper or in any other form outside EESSI;

The Case Owner then identifies the correct institution or institutions (the Counterparty(ies)) in each Member State that are involved in the claim procedure. There will be one Counterparty or more. The Case Owner and the Counterparty(ies) are herein collectively referred to as the Participants;

Send P15000

The Case Owner fills in an Transition of Pension Case to EESSI (P15000) by entering all the required data;

The Case Owner sends the P15000, including any attachments, to all Counterparties;

Process Claim & Send Decision

Each Counterparty will receive a Transition of Pension Case to EESSI (P15000) with the fitting personal ID dataset and any attachments.

The Case Owner then optionally fills in a Report on Insurance and Residence Periods (P5000) which provides detailed insurance information to assist the pension processing;

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

The Case Owner fills in an Pension Decision (P6000) by entering all the required information about the Pension decision they have made;

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

Each Counterparty then optionally fills in a Report on Insurance and

Residence Periods (P5000) which provides detailed insurance information to assist the pension processing;

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

Each Counterparty fills in a Pension Decision (P6000) by entering all the required information about the Pension decision they have made;

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

[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 Decisions

Each time the Contact Institution receives a Pension Decision (P6000) from other Participant, or it sends a P6000, it checks if:

There is at least one valid P6000 or other equivalent information from each Participant involved, that P7000 can be issued.

If this is true, the Contact Institution, OR at the discretion of the Contact Institution, continues to the [Next Step] if not it repeats [This Step];

Finalize Claim

The Contact Institution 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;

The Contact Institution fills in a Summary of Pension Decisions (P7000) by entering specific data provided in the Pension Decisions (P6000) exchanged by all participants;

The Contact Institution sends the P7000 to all Participants.

Upon the sending of the P7000 the Pension Claim is complete

The use case ends here.

Alternative Scenarios:

at any step after [step 5] the Contact Institution may optionally choose to fill in and send Country Specific Information.

The Contact Institution fills in Country Specific Information (P3000_XX) which provides supplementary information to assist the pension processing in the Member State it was designed for;

The Contact Institution sends the P3000_xx to specific Participants (see Special Requirements)

[This Branch] Ends

at any step after [step 5] the Contact Institution, may optionally choose to fill in and send a Report on Insurance History.

The Contact Institution fills in Report on Insurance History (P4000) which provides supplementary information to assist the old-age pension processing;

The Contact Institution sends the P4000 to all Participants

[This Branch] Ends

at any step after [step 5] any Participant may optionally choose to fill in a Request for Additional Information.

The Participant who invokes this branch fills in a Request for Additional Information (P8000) which details the additional information they need;

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)

Each Participant who received a P8000 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 20];

Where [Branch 3 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.

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 21]; [go to Branch 3 Step 1]

[This Branch] Ends

at any step after [step 5] any Participant may optionally choose to fill in a Transfer of Additional Information.

The Participant who invokes this branch fills in a Transfer of Additional Information (P10000) which details the additional information they wish to transfer;

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)

[This Branch] Ends

The Following Branches determine the use of Horizontally Defined Sub Processes within this Business Process

at any step after [step 5] any Participant may optionally choose to request the Reimbursement of Administrative Check or Medical

Examination from another Participant

The Participant executes business use case H_BUC_04_Subprocess – Reimbursement of Administrative Check or Medical Examination;

[This Branch] Ends

at any step after [step 5] any Participant may optionally choose notify another Participant of the Death of a Person

The Participant executes business use case H_BUC_07_Subprocess – Notification of Death;

[This Branch] Ends

at any step after [step 5] any Participant may optionally choose to request and exchange Medical Information with another Participant

The Participant executes business use case H_BUC_08_Subprocess – Medical Information;

[This Branch] Ends

at any step after [step 5] any Participant may optionally choose to notify another Participant of the Medical Information

The Participant executes business use case H_BUC_09_Subprocess – Notification of Medical Information;

[This Branch] Ends

The Following Branches Determine the use of Administrative Sub

Processes within this Business Process

at any step after [step 5] any Participant may choose to Remove participants from this Business Process.

The Participant executes business use case AD_BUC_04_Subprocess – Remove Participant;

[This Branch] Ends

at any step after [step 5] any Participant may choose to Add new participants to this Business Process.

The Participant executes business use case AD_BUC_03_Subprocess – Add Participant;

[This Branch] Ends

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.

The Participant executes business use case AD_BUC_05_Subprocess – Forward Case;

[This Branch] Ends

at any step after [step 5] the Case Owner may choose to advise all recipients of their P15000 that it is Invalid under Art 5 of 987/09

The Case Owner executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

Optionally, the Case Owner fills in P15000, by entering all the required

data;

Optionally, the Case Owner sends the P15000, including any attachments, to all counterparties;

[This Branch] Ends

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

The Case Owner executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

Optionally, the Case Owner fills in P5000, by entering all the required data;

Optionally, the Case Owner sends the P5000, including any attachments, to all counterparties;

[This Branch] Ends

at any step after [step 11] any Participant may choose to advise all recipients of their P5000 that it is Invalid under Art 5 of 987/09

The Participant executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

Optionally, the participant fills in P5000, by entering all the required data;

Optionally, the participant sends the P5000, including any attachments, to all participants;

[This Branch] Ends

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

The Case Owner executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

If no other valid P6000 exists from the Case Owner then the Main Scenario reverts to [step 8].

[This Branch] Ends

at any step after [step 13] any Participant may choose to advise all recipients of their P6000 that it is Invalid under Art 5 of 987/09

The Participant executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

If no other valid P6000 exists for this Participant then the Main Scenario reverts to [step 12].

[This Branch] Ends

at any step after [step 18] the Contact Institution may choose to advise all recipients of their P7000 that it is Invalid under Art 5 of 987/09

The Contact Institution executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

The Main Scenario reverts to [step 16].

[This Branch] Ends.

where [Branch 1 Step 2] has been executed then at any step after [Branch 1 Step 2] the Contact Institution may choose to advise all

recipients of their P3000_xx that it is Invalid under Art 5 of 987/09

The Contact Institution executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

Optionally, the Contact Institution fills in P3000_xx, by entering all the required data;

Optionally, the Contact Institution sends the P3000_xx, including any attachments, to all counterparties;

[This Branch] Ends

where [Branch 2 Step 2] has been executed then at any step after [Branch 2 Step 2] the Contact Institution may choose to advise all recipients of their P4000 that it is Invalid under Art 5 of 987/09

The Contact Institution executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

Optionally, the Contact Institution fills in the P4000, by entering all the required data;

Optionally, the Contact Institution sends the P4000, including any attachments, to all counterparties;

[This Branch] Ends

where [Branch 3 Step 2] has been executed then at any step after [Branch3 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

The Participant executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

Optionally, the participant fills in P8000, by entering all the required data;

Optionally, the participant sends the P8000, including any attachments, to all participants;

[This Branch] Ends

where [Branch 3 Step 4] has been executed then at any step after [Branch 3 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

The Participant executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

Optionally, the participant fills in P9000, by entering all the required data;

Optionally, the participant sends the P9000, including any attachments, to all participants;

[This Branch] Ends

where [Branch 4 Step 2] has been executed then at any step after [Branch 4 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

The Participant executes business use case AD_BUC_06_Subprocess - Invalidate_SED;

Optionally, the participant fills in P10000, by entering all the required data;

Optionally, the participant sends the P10000, including any

attachments, to all participants;

[This Branch] Ends

at any step after [step 5] the Case Owner may choose to send an updated version of P15000

The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

at any step after [step 7] the Case Owner may choose to send an updated version of their P5000

The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

at any step after [step 11] any Participants may choose to send an updated version of their P5000

The Participants executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

at any step after [step 9] the Case Owner may choose to send an updated version of their P6000

The Case Owner executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

at any step after [step 13] any Participants may choose to send an updated version of their P6000

The Participants executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

at any step after [step 18] the Contact Institution may choose to send an updated version of their P7000

The Contact Institution executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

where [Branch 1 Step 2] has been executed then at any step after [Branch 1 Step 2] the Contact Institution may choose to send an updated version of their P3000_xx

The Contact Institution executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

where [Branch 2 Step 2] has been executed then at any step after [Branch 2 Step 2] the Contact Institution may choose to send an updated version of their P4000

The Contact Institution executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

where [Branch 3 Step 2] has been executed then at any step after [Branch 3 Step 2] the Participant who sent the P8000 may choose to send an updated version of their P8000

The Participant executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

where [Branch 3 Step 4] has been executed then at any step after [Branch 3 Step 4] the Participant who sent the P9000 may choose to send an updated version of their P9000

The Participant executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

where [Branch 4 Step 2] has been executed then at any step after [Branch 4 Step 2] the Participant who sent the P10000 may choose to send an updated version of their P10000

The Participant executes business use case AD_BUC_10_Subprocess - Update_SED;

[This Branch] Ends

at any step after [step 5] 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.

The Participant who invokes this branch executes business use case AD_BUC_07_Subprocess -_Reminder;

[This Branch] Ends

Exceptions:

Includes:

See diagram at part 4.4

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 3] – May be invoked more than once, per Participant

[Branch 4] – May be invoked more than once, per Participant

Horizontals

[Branch 6] – May only be invoked once, per Participant

[Branch 5,7,8] - May be invoked more than once, per Participant

Administrative

[Branch 9] to [Branch 10] – May be invoked more than once, per Participant

[Branch 11] – May only be invoked once, per Participant

[Branch 12] to [Branch 34] – May be invoked more than once, per Participant

SR3: Rules about the destination for each SED Type when the SED is sent:

P15000 – 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 10] and/or [Branch 11] and not removed through the execution of [Branch 9] and/or [Branch 11]

SR6: Alternative Branches 11 – 12 are interrupting Branches;

Alternative Branches 1 – 10 are non-interrupting Branches;

Alternative Branches 13 – 34 are non-interrupting Branches;

SR7: Clarification: where two or more institutions from the same MS are involved in the case, only one P6000 or other equivalent information needs to be exchanged from that MS to satisfy this rule.

SR8: "at the discretion of the Contact Institution" – allows under exceptional circumstances for the Contact Institution 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

P3000_XX

Allowed

P4000

Allowed

P5000

Not Allowed

P6000

Allowed

P7000

Not Allowed

P8000

Allowed

P9000

Allowed

P10000

Allowed

P15000

Allowed

Artefacts used

The following table specifies the artefacts that are used in this Business Use Case.

Artefacts name

Artefacts type

P15000

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

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

Business Processes

This chapter describes the Business Use Case Transitional Cases.

Case Owner and Counterparty

5.2. Sub Processes

5.2.1. ContactInstitutionSP

5.2.2. OtherInstitutionSP

Appendices

Issues

Issue date

Description

Replies

Action/Resolution

Close date