S_BUC_08 Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State)
ApprovedApprovedEESSI Business Use CaseEESSI Business Use Case Approved Approved EESSI Business Use Case EESSI Business Use Case Annex Nr.14 to the note AC 370/16revAnnex Nr.14 to the note AC 370/16rev Annex Nr.14 to the note AC 370/16rev Annex Nr.14 to the note AC 370/16rev S_BUC_08 Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State)S_BUC_08 Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) S_BUC_08 Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) S_BUC_08 Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) Table of Contents Table of Contents 2
1. Introduction 8
1.1. Purpose 8
1.2. Scope 8
1.3. Definitions, Acronyms and Abbreviations 8
1.4. References 9
1.5. Overview 9
2. Description 10
2.1. Business Scenario 10
2.2. Legal Base 10
3. Actors & Roles 11
4. Use Case 12
4.1. RUP Table Representation 12
4.2. Request – Reply SEDs 15
4.3. Attachments Allowed 15
4.4. SED and Sub-process Versioning 15
5. Business Processes 17
5.1. Case Owner and Counterparty 17
5.2. Sub Processes 18
6. Appendices 19
6.1. Issues 19
Document Control Information Settings Value Document Title: Business Use Case S_BUC_08 Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) Project Title: EESSI (Electronic Exchange of Social Security Information) Project Document Author: European Commission, DG EMPL F5 Project Owner: European Commission, DG EMPL D2 Doc. Version: V4.1.0 Sensitivity: Public 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 10/01/2015 Mirko Brusca First draft v0.2 21/04/2015 Mirko Brusca Final Review after Chris Segaert and Alyson LONGSTAFF Review. v0.3 13/08/2015 Carine Molle Document history : table is now in reverse chronological order. Chapter 2 :
2.1 last sentence of paragraph has been modified
2.2 Basic Regulation No 883/994 has been replaced by No 883/2004
Chapter 4 : Modification based on AHG remark (S075 and S076 should be a repeatable process) Small modification based on Test Team review (split big task in smallest ones) Chapter 5 : Section 5.3 : - Diagram for "Identify Participants" sub-process has been added - Diagram for "Request Info" sub-process has been replaced by the new one Grammatical corrections (minor correction) based on feedback received from Alyson LONGSTAFF in another BUC. v0.4.0 20/01/2016 Carine Molle Parts of the document have been added in order to be in line with document presentation and content to be approved by Administrative Commission. As agreed during the AHG Members meeting 04/11/2015: H_BUC_01 is added for Case Owner AD_BUC_05 Forward is added for Counterparty Claimant is removed from the BUC. Chapter 2
2.1 Business Scenario is renamed and updated. Last sentence is removed
2.2 Legal Base is updated
Chapter 3 Actors & Roles Claimant is removed Chapter 4
4.1 RUP Table Representation
"Actors" – Claimant is removed "Main scenario" – Step 8 is added "Exceptions" is added "Includes" is updated "Alternatives scenarios": - Branch 2 : H_BUC_01 is added for Case Owner - Branch 3 : AD_BUC_05 Forward is added for Counterparty "Special Requirements" is updated according to the branches added
4.2 Request – Reply SEDs is added
4.3 Attachments Allowed is added
4.4 RUP UC Diagram is updated (H_BUC_01 and AD_BUC_05 are added, Claimant is removed)
4.5 SED and Sub-process Versioning is added
Chapter 5
5.1 Case Owner (BPMN is updated – Claimant is removed and H_BUC_01 is added)
5.2 Counterparty (BPMN is updated – AD_BUC_05 is added)
5.3 Called Sub Processes
Identify Participants BPMN is updated
5.4 Main Scenario is removed
Chapter 6 Section 6.1 Related Use Cases is removed Section 6.2 Privacy and Security Assumptions is removed Version number of the document has been changed to be in line with the convention M.m.p where : - M = Major version (e.g. Approved by AC) - m = Minor version (e.g. changes in the process) - p = Patch version (e.g. wording…any changes without any impact on the process itself) v0.5.0 01/03/2016 Carine Molle As requested H_BUC_01 is added for the Counterparty. Section 4 : RUP Table Representation Branch 1 : details have been added Branch 3 is added (H_BUC_01 for the Counterparty). Other branch is renumbered. Branch 4 : At [step 5] is replaced by After [step 5] and before [step 6] Section 5 BPMN diagram has been replaced Section 6.1 comment on issue 1 received from Belgium is added v0.99.0 15/04/2016 Carine Molle Candidate for AC Approval as agreed by the Sickness rapporteur. v1.0.0 28/06/2016 Valérie Banchereau Status logo set to 'Approved' following AC approval of June, 20th 2016. Alignment to the standard description and layout of the BUC. v1.1.0 13/06/2017 Joël Fiora Change Request EESSI-1798: As agreed by AHG members, "AD_BUC_07 – Reminder" has been added for Case Owner and Counterparty: - Correction Section 4: description of Branches 'Reminder' – Branches 4 and 5 -Correction Section 4, Branch 1 and 2, withdraw the use of H_BUC_01 as 'Reminder' Change Request EESSI-1849: "H_BUC_01" is added for the Case Owner "H_BUC_08" is added for the Counterparty and replaces S075 and S076 Section 4.1 has been updated (Branch 4 and 5 added) Section 4.4 has been updated (Reminder is added) Section 4.5 SED and Sub-process Versioning: H_BUC_01 and H_BUC_08 are added) S075 and S076 are removed v1.1.1 03/07/2017 Joël Fiora - Included BPMN picture in section 5 - removed Use Case diagram v4.1.0 09/08/2018 Eric Briffoz - Section 4.4: merged 2 tables (for SED & for Subprocesses) into 1 Artefact table. - Version adaptations to release 4.1.0.
1. Introduction
1.1. 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 any 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, and business processes. 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.
1.2. Scope
This document is limited to the external view of the Sickness' sector process concerning Scheduled Treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State). The different elements like use case description, business actors, and business process as well as supporting UML diagrams and BPMN models pertaining to the Scheduled Treatment - Information on Coverage of Specific Benefit in Kind case.
1.3. Definitions, Acronyms and Abbreviations
Please see the EESSI Project Glossary here
1.4. References
# Description EC Regulation 883/2004 Regulation EC No 883- 2004.pdf EC Regulation 987/2009 Regulation EC No 987-2009.pdf UML 2.x http://www.omg.org/spec/UML/ BPMN 2.0 http://www.omg.org/spec/BPMN/index.htm UML 2.0 In Action Henriette Baumann, Patrick Grassle & Philippe Baumann, 2005, ISBN 1904811558 RUP@EC standard 5.0 http://www.cc.cec/RUPatEC_Standard/ RUP op maat http://www.rupopmaat.nl/
1.5. Overview
Chapter 1 introduces the external view on the business system under review and lists the elements of this specification. Chapter 2 introduces the Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) 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 Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) business process. Chapter 4 describes in detail the Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) business process based on the RUP use case template, as well as the relationship to other use cases. Chapter 5 describes the Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) business process using business process modelling notation (BPMN).
2. Description
2.1. Business Scenario
This BUC allows the institution of the Member State of residence, in case it is not the competent institution to issue an authorisation, to forward the request for an authorisation made an insured person/pensioner to the competent institution. The competent institution subsequently decides if an authorisation is granted or not, and • issues a portable document S2 to the person concerned, • and informs the institution of the Member State of residence of its decision.
2.2. Legal Base
This Business Use Case document's the legal base is described in the following Regulations - Basic Regulation (EC) No 883/2004 - Implementing Regulation (EC) No 987/2009 The following matrix specifies the SEDs that are used in this Business Use Case and documents the articles that provide the legal basis for each SED. SED Basic Reg (883/04) Implementing Reg (987/09) S009 S010 Table 1: SED – Legal base relationship matrix
3. Actors & Roles
This chapter captures details of the actors which are important to understand the different types of system users. An actor is anyone or anything that exchanges data with the business system. An actor can be a user, external hardware or another system. The overarching description of each actor described in this Business Use Case can be found in the Glossary. Below you will find a short description which provides further clarity of this actor within the context of this Business Use Case. Actor name Description Case Owner In this BUC the Case Owner is Institution of the Member State of Residence to which the insured person/pensioner is requesting the authorization Counterparty In this BUC The Counterparty is the Institution of the competent Member State entitled to grant an authorization to receive an appropriate treatment. Table 2: Actors & Roles
4. Use Case
4.1. RUP Table Representation
Use Case ID: S_BUC_08 Use Case Name: Scheduled treatment - Request Entitlement Document in Member State of Stay (Residence not in competent Member State) Created By: Mirko Brusca Last Updated By: Carine Molle Date Created: 10/01/2015 Last Revision Date: 01/03/2016 Actors: Case Owner Counterparty Description: This case deals with the situation when an insured person/pensioner, who does not reside in the competent Member State, requests the institution of his/her place of residence for an authorisation for a scheduled treatment outside the Member State of residence. The institution of the place of residence examines whether the conditions to issue an authorisation in the Member State of residence are met or not, and informs the competent institution of its conclusions. Trigger: An insured person/pensioner (claimant), who does not reside in the competent Member State, requests the institution of his/her place of residence for an authorisation for a scheduled treatment outside the Member State of residence Preconditions: The insured person stays outside the residence Member State and the competent Member State if the latter one is mentioned in Annex IV of Regulation (EC) 883/2004. Currently the Member States mentioned in the ANNEX IV are: Belgium, Bulgaria, Czech Republic, Germany, Greece, Spain, France, Cyprus, Luxemburg, Hungary, Netherlands, Austria, Poland, Slovenia and Sweden, as well as Iceland, Liechtenstein and Switzerland. The institution of the Member State of residence is not competent for issuing an authorisation (Member State is not mentioned in ANNEX 3 of Regulation (EC) 987/2009. Post Conditions: The competent institution decides if an authorisation is granted or not, and - issues a portable document S2 to the person concerned, - informs the institution of the Member State of residence of its decision. Main Scenario: Identify Participants 1. The Case Owner (Institution of Member State of Residence) identifies the Competent Member State entitled to issue the authorisation; 2. The Case Owner then identifies the correct institution in the Competent Member State. There will be only one counterparty. The Case Owner and the Counterparty are herein collectively referred to as the Participants; Request for entitlement document 3. The Case Owner fills in the "Request for entitlement document - scheduled treatment outside Member State of residence " (S009) entering information about its conclusions and attaching all relevant medical data (medical report, treatment options, medical evaluation/examination by a medical officer, ...);
4. The Case Owner sends the S009 to the Counterparty.
Reply to the request
5. The Counterparty receives the request for entitlement document (S009);
6. The Counterparty fills in a " Reply to request for Entitlement Document - scheduled treatment outside Member State of residence " (S010) specifying its decision;
7. The Counterparty sends the S010 to the Case Owner;
8. The Case Owner receives the S010.
9. This use case ends here.
Alternative Scenarios: The Following Branches determine the use of Horizontally Defined Sub Processes within the Business Process Branch 1:. At any step after [step 7] the Counterparty may optionally choose to request medical information from Case Owner
1. The Counterparty executes business use case H_BUC_08 – Medical Information
2. [This Branch] Ends
Branch 2:. At any step after [step 8] the Case Owner may optionally choose to request AdHoc Information from Counterparty
1. The Case Owner executes business use case H_BUC_01 – Adhoc Exchange of Info;
2. [This Branch] Ends
The Following Branches determine the use of Administrative Defined Sub Processes within the Business Process Branch 3:. At any step after [step 5] the Counterparty may optionally choose to Forward this Business Process to another Institution within its MS who assumes responsibility for changing it
1. The Counterparty executes business use case AD_BUC_05 – Forward Case;
2. [This Branch] Ends.
Branch 4:. after Branch 1 [step 1] Counterparty may optionally choose to send a reminder in order to receive the Information expected and not yet received
1. The Counterparty executes business use case AD_BUC_07 -_Reminder;
2. [This Branch] Ends
Branch 1:. At any step after [step 4] Case Owner may optionally choose to send a reminder in order to receive Information expected and not yet received.
1. The Case Owner executes business use case AD_BUC_07_ -_Reminder;
2. [This Branch] Ends
Exceptions: None Includes: See diagram at part 4.4 Special Requirements: SR0: General Rule As the request is individualized the case can concern only one person. SR1: Rules about invoking of Branches [Branch 1] – May be invoked more than once [Branch 2] – May be invoked more than once [Branch 3] – May be invoked once when the first SED is received by Counterparty and before sending the answer [Branch 4] – May be invoked more than once. [Branch 5] – May be invoked more than once . Assumptions: Notes and Issues:
1.1. 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) S009 S010
1.2. Attachments Allowed
The following table specifies whether attachments are permitted to be included when sending a SED type. SED Attachments S009 Allowed S010 Allowed
1.3. Artefacts used
The following table specifies the artefacts that are used in this Business Use Case. Artefact name Artefact type S009 SED S010 SED H_BUC_01_Subprocess BUC H_BUC_08_Subprocess BUC AD_BUC_05_Subprocess – Forward Case BUC AD_BUC_07_Subprocess – Reminder BUC AD_BUC_11_Subprocess – Business Exception BUC AD_BUC_12_Subprocess – Change of Participant BUC
5. Business Processes
The following paragraphs describe the Business Use Case Scheduled treatment - Request Entitlement Document in Member State of Stay using BPMN 2.0.
5.1. Case Owner and Counterparty
Figure 2: depicts the use case end-to-end for the Case Owner and Counterparty, from a high level.
5.2. Sub Processes
Not applicable.
6. Appendices
6.1. Issues
# Issue date Description Replies Action/Resolution Close date 20/01/2016 H_BUC_01 has not been added for the Counterparty while this participant can use the exchange of S075 – S076 in order to request additional information from the Case Owner. But it means in the same time, that no "reminder" can be sent to the Case Owner. What do you think about this ? BE COMMENT (08.02.2016) We have the possibility of exchanging S075-S076 for additional information, and indeed, it means that no “reminder” can be sent to the Case Owner. However, would adding H_BUC_01 between steps 5 and 6 not create more confusion, i.e. a S- and a H-procedure to ask for more information? Why would that be an issue in this BUC but not in S_BUC_09 v0.5.0 where we have a similar situation? H_BUC_01 will be added. 01/03/2016 28/06/2016 Conversion of the BPMN to split between Case Owner and Counterparty. Scheduled for update.