S_BUC_17a - Long-Term Care - Change of Entitlement to Benefits in Kind
EESSI Business Use CaseEESSI Business Use Case EESSI Business Use Case EESSI Business Use Case S_BUC_17aLong-Term Care - Change of Entitlement to Benefits in KindS_BUC_17aLong-Term Care - Change of Entitlement to Benefits in Kind S_BUC_17a Long-Term Care - Change of Entitlement to Benefits in Kind S_BUC_17a Long-Term Care - Change of Entitlement to Benefits in Kind Table of Contents
1 Introduction 6
1.1 Purpose 6
1.2 Scope 6
1.3 Definitions, Acronyms and Abbreviations 6
1.4 References 7
1.5 Overview 7
2 Description 8
2.1 Business Scenario 8
2.2 Legal Base 8
3 Actors & Roles 9
4 Use Case 10
4.1 RUP Table Representation 10
4.2 Request – Reply SEDS 13
4.3 Attachments Allowed 13
4.4 Artefacts used 14
5 Business Processes 15
5.1 Sub Processes 16
6 Appendices 17
6.1 Issues 17
Document Control Information Settings Value Document Title: Business Use Case S_BUC_17a - Long-Term Care - Change of Entitlement to Benefits in Kind 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: Internal Date: 09/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 07/03/2016 Valérie Banchereau First draft of the document. v0.1.1 07/06/2016 Valérie Banchereau Comments received from Germany have been accepted. Title of the BUC has been changed. Section 2.2 Legal base: art 28 is removed Section 4.1- RUP Table Description Pre-conditions is updated Post conditions is updated Section 6.1 Issues updated with the remarks and comments received. v0.2.0 28/06/2016 Valérie Banchereau Alignment to the standard description and layout of the BUC. Section 2.1: Business scenario slightly adapted following Germany's proposal. Section 6.1, issue 4: Germany proposes to add special requirements. Section 6.1, issue 6: Germany proposes to make section 4 of SED S005 repeatable. v0.3.0 09/11/2016 Carine Molle Remarks and last comments received from Germany have been accepted in the document. Comments received from AC have been implemented in the document. As suggested "Reminder" and "Reject" have been added for the Counterparty. Section 4.1 has been updated (Branch 3 and 4 added) Section 4.4 has been updated (Reminder and Reject added) Section 4.5 SED and Sub-process Versioning (Reminder and Reject are added) v0.99.0 23/11/2016 Carine Molle As agreed by AHG members: "Invalidate" will be added Section 4.1 is updated Branch 5: "Invalidate" is added for Case Owner Section 4.4 RUP UC Diagram Representation is updated Section 4.5 SED and Sub-process Versioning is updated Submitted for AC Approval v1.0.0 15/12/2016 Heidi Warson AC Approved Version v1.0.1 03/07/2017 Joël Fiora -Included BPMN picture in section 5 -Correction in the horizontal sub-process table in section 4.5 - removed Use Case diagram v4.1.0 09/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. Introduction Purpose The purpose of this document is to construct an external view 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, 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 utilises. 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 of the Sickness´ sector process concerning Long-Term Care - Change of Entitlement to Benefits in Kind. The different elements like use case description, business actors, and business process as well as supporting UML diagrams and BPMN models pertaining to Long-Term Care Change of Entitlement to Benefits in Kind. 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 the Long-Term Care - Change of Entitlement to Benefits in Kind business process. This chapter gives a short and detailed description as well as a reference to the business process´ legal base. Chapter 3 lists the actors involved in the Long-Term Care - Change of Entitlement to Benefits in Kind business process. Chapter 4 describes in detail the Long-Term Care - Change of Entitlement to Benefits in Kind business process based on the RUP use case template, as well as the relationship to other use cases. Chapter 5 describes the Long-Term Care - Change of Entitlement to Benefits in Kind business process using business process modelling notation (BPMN). Description Business Scenario An insured person residing or staying in a Member State other than the competent Member State may be entitled to long-term care cash benefits provided by the competent institution in accordance with the legislation it applies. If in the same time, the concerned person receives long-term care benefits in kind for the same purpose from the Member State of residence or stay, the general provision on prevention of overlapping of benefits shall be applicable. This Business Use case enables the institution of the Member State of Residence/Stay to inform the institution of the Competent Member State about any change concerning the benefits in kind granted under its legislation in order to allow the competent institution to adapt the amount of cash benefits if necessary. It is up to the competent institution to decide which benefits in kind have to be taken into account for the reduction of cash benefits. 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/2004) implementing Reg.(987/2009) S005 Table 1: SED – Legal base relationship matrix 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 the institution of the place of residence/stay which sends to the institution of the Competent Member State information concerning any change related to long-term care benefits in kind. Counterparty In this BUC, the Counterparty is the institution in the Competent Member State which receives from the institution of the Member State of residence/stay information about any change related to long-term care benefits in kind. Table 2: Actors & Roles Use Case RUP Table Representation Use Case ID: S_BUC_17a Use Case Name: Long-Term Care - Change of Entitlement to Benefits in Kind Created By: Valérie Banchereau Last Updated By: Carine Molle Date Created: 07/03/2016 Last Revision Date: 23/11/2016 Actors: Case Owner Counterparty Description: This particular case enables the institution of the Member state of Residence/Stay to inform the institution of the Competent Member State about changes concerning benefits in kind granted under its legislation in order to allow the institution of the Competent Member State to adapt the amount of cash benefits if necessary. Trigger: The institution of the Member State of Residence/Stay informs the institution of the Competent Member State that the amount of benefits in kind communicated with SED S003 changed. Preconditions: The insured person resides or stays outside the Competent Member State. The insured person receives long-term care benefits in kind from the Member State of residence / stay. The S_BUC 15 or S_BUC 17 already took place between both States in that case. Post conditions: If applicable the competent institution adapts the amount of its long-term care cash benefits. Main Scenario: Identify Participants 1. The Case Owner identifies the competent institution by checking who sent SED S001 or SED S056. The Competent institution is the Counterparty. There will be only one counterparty. The Case Owner and the Counterparty are herein collectively referred to as the Participants. Send Information on Change of Entitlement to Benefits in Kind – Long term care 2. The Case Owner fills in the "Information on Change of Entitlement to Benefits in Kind – Long term care" SED (S005) by entering all required data; 3. The Case Owner sends the "Information on Change of Entitlement to Benefits in Kind – Long term care" SED (S005) to the Counterparty; 4. The Counterparty receives the 'Information on Change of Entitlement to Benefits in Kind – Long term care' SED (S005);
5. This use case ends here.
Alternative Scenarios: Following Branches Determine the use of Horizontal Processes within this Business Process Branch 1:. After [step 5] Counterparty may optionally choose to request Ad Hoc Information from Case Owner. 1. The Counterparty executes business use case H_BUC_01 – Ad Hoc Exchange of Info;
2. [This Branch] Ends.
Following Branches Determine the use of Administrative Processes within this Business Process Branch 2:. After [step 5] Counterparty may optionally choose to Forward this Business Process to another Competent Institution within its Member State who assumes responsibility for handing it
1. The Counterparty executes business use case AD_BUC_05 – Forward Case;
2. [This Branch] Ends.
Branch 3:. After [step 5] Counterparty may optionally choose to send a reminder in order to receive the answer to Ad Hoc Information expected and not yet received.
1. The Counterparty executes business use case AD_BUC_07 – Reminder;
2. [This Branch] Ends.
Branch 4:. After [step 5] Counterparty may optionally choose to notify the Case Owner that they Reject a SED they have received.
1. The Counterparty executes business use case AD_BUC_09 – Reject SED;
2. [This Branch] Ends.
Branch 5:. At any step after [step 4] the Case Owner may choose to advise the Counterparty that their S005 is Invalid under Art 5 of 987/09
1. The Case Owner executes business use case AD_BUC_06_- Invalidate_SED;
2. Optionally, the Case Owner fills in an "Information on Change of Entitlement to Benefits in Kind – Long term care" (S005) by entering all the required data; 3. Optionally, the Case Owner sends the S005, including any attachments, to the Counterparty;
4. [This Branch] Ends.
Exceptions: None Includes: See diagram at part 4.4 Special Requirements: SR0 : General Rule As the request is individualised, the case can concern only one person. SR1: Rules about the invoking of Branches: Horizontal [Branch 1] – May be invoked more than once; Administrative [Branch 2] – May be invoked once only when the first SED is received by Counterparty. [Branch 3] – May be invoked more than once. [Branch 4] – May be invoked once and is an interrupting branch. [Branch 5] – May be invoked more than once. Assumptions: Notes and Issues: 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) None None Attachments Allowed The following table specifies whether attachments are permitted to be included when sending a SED type. SED Attachments S005 Allowed Artefacts used The following table specifies the artefacts that are used in this Business Use Case. Artefact name Artefact type S005 SED H_BUC_01_Subprocess BUC AD_BUC_05_Subprocess – Forward Case BUC AD_BUC_06_Subprocess – Invalidate SED BUC AD_BUC_07_Subprocess – Reminder BUC AD_BUC_09_Subprocess – Reject 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 Long-term Care – Change of Entitlement to Benefits in Kind. using BPMN 2.0. Figure 2: depicts the use case end-to-end for the Case Owner and Counterparty, from a high level, using the BPMN 2.0 collaboration diagram. Sub Processes Not applicable. Appendices Issues # Issue date Description Solution Close date 07/03/2016 SED S005 mentions article 28 of Regulation (EC) 987/2009. This article is not mentioned in the Guidelines. Answer from Germany (26/04/2016): 'Remove article 28 from SED S005. ' Art 28 is removed from Section 2.2 Legal base. It will be removed from the SED S005 with the version 4. (JIRA ticket EESSIDRY-1426). 07/06/2016 26/04/2016 Comment from GE: 'The title of the BUC is wrong. I guess this is due to a mistake in the guidelines (p.72). In this BUC, the institution of the country of residence/stay informs about any change or cancellation of long-term care benefits in kind. The title of SED S005 is right. ' Title of the BUC has been changed according to Germany's comment. Sickness Guidelines should be adapted accordingly. 07/06/2016 26/04/2016 Germany proposes to change numbering in SED S005 (see the proposition hereafter) 'If I want to provide information on the end of the benefit, it should not be compulsory to restate information on start date. New numbering from 4.1.1to 4.1.4 allows distinguishing better between “change of benefits” and “end of benefits” situations.'
4. Change of entitlement to benefits in kind – long term care*
4.1 Start date
[DD/MM/YYYY].....................................................
4.1.1 Amount*
[decimal]...........................................................
4.1.2 Currency*
[From world Currency list]..............................
4.1.3 Frequency of payment*
Daily Weekly Monthly Other Please fill in the following if "Frequency of payment" = "Other" :
4.1.4 Other
[155].......................
4.2 End date
[DD/MM/YYYY].....................................................
4.3 Description of the benefit(s)
[500]....................... To be discussed with other AHG members. NB: This would have an impact on proposed SICKNESS Sector component 'SICKNESS.PaymentDetails'. 07/06/2016 26/04/2016 Section 4.5 - SED and Sub-process Versioning, comments from Germany: 'From my point of view AD_BUC_11 requires that competent institutions as well as AP provider work with a kind of BUC-state control engine. I doubt whether this is in line with our general approach. How can we manage that this issue will be discussed and solved?' There is a difference between the implementation and the rules. It should probably be controlled at the national level application, but the rules, if implemented on national level, should be described somewhere. This document captures this kind of requirements and behaviour. Germany proposes to mention that MS are in charge of implementing these rules at national level under special requirements section. 07/06/2016 28/06/2016 Conversion of the BPMN to split between Case Owner and Counterparty. Scheduled for update. 23/08/2016 Germany proposes to make section 4. Of SED S005 repeatable in order to share information about several sorts of payments. In many cases in the area of long-term care, payments are made ad-hoc or as lump sum, but there are also monthly payments… LTC- SEDs should be able to adapt to this variety. This will be handled in V4 of the SED (see JIRA ticket EESSIDRY-1426) 09/11/2016 "Reminder" and "Reject" admin BUC should be added on BPMN diagram for the Counterparty. Scheduled for update. 23/11/2016 "Invalidate" admin BUC should be added on BPMN diagram for the Case Owner. Scheduled for update.