S_BUC_05 - Necessary Treatment in Member State of Stay - Request for Entitlement Document | Lexipedia

EESSI Business Use Case

APPROVED

S_BUC_05

Necessary Treatment in Member State of Stay - Request for Entitlement Document

S_BUC_05

Necessary Treatment in Member State of Stay - Request for Entitlement Document

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 14

4.3. Attachments Allowed 14

4.4. Artefacts used 14

5. Business Processes 15

5.1. Main Process 15

Sub Processes 16

6. Appendices 17

6.1. Issues 17

Document Control Information

Settings

Value

Document Title:

Business Use Case -

S_BUC_05 - Necessary Treatment in Member State of Stay - Request for Entitlement Document

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:

09/08/2018

Document history:

The Document Author is authorised 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

12/10/2015

Carine Molle

First draft of the document

06/11/2015

Carine Molle

As decided during the Sickness AHG Meeting on 4/11/2015

Add call to sub-process AdHoc Information (H_BUC_01)

Delete "Claimant" information

6.1 Admin Process

This point has been added with all admin processes available and suggestions to used the "Forward" and "Reject".

v0.2

11/12/2015

15/12/2015

Carine Molle

Document has been updated with remarks and feedbacks received from MS.

Section 4.1: Description of the BUC has been updated as proposed by Finland

Branch 2 is added (H_BUC_01) available for Case Owner

Branch 3 is added (Forward) for Counterparty

Section 4.4: RUP UC Diagram Representation updated

Section 5.1: Case Owner and Counterparty BPMN updated

Document has been updated in order to be in line with presentation and content as proposed for the approval by the Administrative Commission

Section 2.1: last sentence is removed

Section 2.2 minor updates

Section 4.2: Request – Reply SEDs added

Section 4.3: Attachments allowed added

Section 4.5: SED and Sub-process versioning added

Section 5.3 is removed

Section 6.1 is removed while replaced by section 4.5

v0.2.1

15/01/2016

Carine Molle

Document has been updated with remarks / questions and feedbacks received from Germany and Belgium

Minor changes which do not impact the process itself have been implemented through the document.

Section 2.1: Detailed description

Last paragraph has been removed.

Section 5.2: Called sub-processes

"Identify participants" has been updated.

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

09/02/2016

Carine Molle

Comments received from DE have been implemented.

Section 2.1 is renamed

Art 27(1) of 883/04 has been added

Section 2.2 Legal Base

Art 27(1) Basic Reg (883/04) has been added

In all sections of the document :

"Entitlement document" is replaced by "Confirmation of entitlement"

v0.3.0

21/06/2016

Valérie Banchereau

Alignment to the standard description and layout of the BUC.

v0.99.0

21/09/2016

Carine Molle

Candidate for AC approval.

Remaining AC comments will be discussed during the AHG meeting the 4th October 2016.

More details related to these comments can be found in section 6.1 of this document

v0.99.1

17/11/2016

Carine Molle

Last comments received from Germany and agreed by AHG members have been accepted in the document.

As agreed by AHG members

"Reminder" has been added for Case Owner and Counterparty.

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 (Reminder is added)

Submitted for AC Approval

v1.0.0

15/12/2016

Heidi Warson

AC Approved Version

v1.0.1

29/06/2017

Joël Fiora

-Included BPMN picture in section 5

-Correction in horizontal sub process table in section 4.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.

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 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 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 Necessary treatment in Member State of Stay – Request for Entitlement Document. The different elements use case description, business actors, and business process as well as supporting UML diagrams and BPMN models pertaining to Necessary treatment in

Member State of Stay – Request for Entitlement Document.

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 Necessary treatment in Member State of Stay – Request for Entitlement Document 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 Necessary treatment in Member State of Stay – Request for Entitlement Document business process.

Chapter 4 describes in detail the Necessary treatment in Member State

of Stay – Request for Entitlement Document business process based on the RUP use case template, as well as the relationship to other use cases.

Chapter 5 describes the Necessary treatment in Member State of Stay – Request for Entitlement Document business process using business process modelling notation (BPMN).

Description

Business Scenario

As the regulation dictates (Art. 25 of 987/09 and Art. 19, 27 (1) of 883/04) the insured person and/or members of the insured persons family staying in a Member State other than the Competent Member State shall be entitled to the benefits in kind which become necessary on medical grounds during their stay, taking into account the nature of the benefits and the expected length of stay. These benefits shall be provided on behalf of the Competent Institution by the Institution of the Place of Stay.

To receive benefits in kind in the Member State of Stay, the insured person shall present to the health care provider in the Member State of Stay a document issued by the competent institution indicating the insured person's entitlement to health benefits in kind. If the insured person does not have such a document, the Institution of the Place of Stay, upon request shall contact the Competent Institution in order to obtain one.

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/04)

Implementing Reg (987/09)

27(1)

25 (1)

25 (2)

25 (3)

S044

S045

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 Member State of Stay which, contacts the institution in the Competent Member State to obtain the confirmation of entitlement to health benefits in kind for a temporary stay.

Counterparty

In this BUC the Counterparty is the Institution of the Competent Member State which has to provide the confirmation of entitlement document for health benefits in kind when an insured person needs necessary treatment during his/her temporary stay in another Member State.

Table 2: Actors & Roles

Use Case

RUP Table Representation

Use Case ID:

S_BUC_05

Use Case Name:

Necessary treatment in Member State of Stay – Request for Entitlement Document

Created By:

Carine Molle

Last Updated By:

Carine Molle

Date Created:

12/10/2015

Last Revision Date:

23/11/2016

Actors:

Case Owner

Counterparty

Description:

This particular case deals with the situation where an insured person or his/her family member needs necessary treatment during their temporary stay in another Member State other than the Competent one but does not have an entitlement document with them. The Member State of Stay requests the confirmation of entitlement from the Competent Member State.

Trigger:

The institution of the Member State of Stay is requested to contact the Institution in the Competent Member State of the insured person to obtain an entitlement document for health benefits in kind in the situation of a temporary stay.

Preconditions:

The insured person or his/her family member stays temporarily outside the competent Member State.

The insured person or his/her family member requires necessary medical treatment to be provided in the Member State of Stay.

The insured person or his/her family can not present to the health care provider in the Member State of Stay the appropriate entitlement document for health benefits in kind in case of temporary stay.

Post conditions:

The Competent Institution provides to the Institution of the MS of Stay a confirmation of entitlement for a temporary stay indicating the entitlement to health benefits in kind for the insured person or his/her family member. If the person is not entitled to benefits in kind, the Competent Institution states the reason for no-entitlement.

Main Scenario:

Identify Participants

The Case Owner (Institution in Member State of Stay) identifies the Competent State where the person is entitled to health benefits in kind;

The Case Owner then identifies the correct institution in Competent Member State. There will be only one counterparty. The Case Owner and the Counterparty are herein collectively referred to as the Participants.

Process to request entitlement document for a temporary stay

The Case Owner fills in the Request for Entitlement Document – Temporary Stay (S044) by entering requested information;

Information about "starting / ending date of entitlement" is

required;

The Case Owner sends the S044 to the Counterparty.

Process Request & Release the entitlement document

The Counterparty receives the S044;

The Counterparty fills in the Entitlement Document – Temporary Stay (S045) to inform the Member State of Stay about the entitlement;

The Counterparty sends the S045 to the Case Owner;

The Case Owner receives the Entitlement document – Temporary Stay (S045) containing the information on the entitlement or the reason for non-entitlement;

This use case ends here.

Alternative Scenarios:

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

Between [step 5] and [step 6] the Counterparty may optionally choose to request AdHoc Information from Case Owner

The Counterparty executes business use case H_BUC_01 – Adhoc Exchange of Info;

[This Branch] Ends.

After [step 8] the Case Owner may optionally choose to request AdHoc Information from Counterparty

The Case Owner executes business use case H_BUC_01 – Adhoc Exchange of Info;

[This Branch] Ends.

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

At [step 5] the Counterparty may optionally choose to Forward this Business Process to another Competent Institution within its MS who assumes responsibility for handling it

The Counterparty executes business use case AD_BUC_05 – Forward Case;

[This Branch] Ends.

After Branch 1 [Step .1] Counterparty may optionally choose to send a reminder in oder to received the answer to Ad Hoc Information

expected and not yet received

The Counterparty executes business use case AD_BUC_07_ -_Reminder;

[This Branch] Ends

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.

The Case Owner executes business use case AD_BUC_07_ -

_Reminder;

[This Branch] Ends

Exceptions:

None

Includes:

See diagram at 4.4

Special Requirements:

SR0: General Rule

As the registration is individualised the case can concern only one person.

SR1: Rules about invoking of Branches:

Horizontal

[Branch 1] – May be invoked more than once.

[Branch 2] – May be invoked more than once.

Administrative

[Branch 3] – May be invoked once only 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:

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)

S044

S045

Attachments Allowed

The following table specifies whether attachments are permitted to be included when sending a SED type.

SED

Attachments

S044

Allowed

S045

Allowed

Artefacts used

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

Artefact name

Artefact type

S044

SED

S045

SED

H_BUC_01_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

Business Processes

This chapter describes the Business Use Case Necessary Treatment in Member State of Stay – Request for Entitlement Document using BPMN 2.0.

Main Process

Figure 3: depicts the use case end-to-end for the Case Owner and Counterparty, from a high level.

Sub Processes

Not Applicable

Appendices

Issues

Issue date

Description

Replies

Action/Resolution

Close date

06/11/2015

Could the "Forward" option be used in this BUC after the counterparty has received the S044 in order to Forward the case to the right institution in his Member State

As agreed, Forward will be available at the beginning of the process

Document updated

15/12/2015

06/11/2015

Could the "Reject" option be used in this BUC after the counterparty has received the S044 in order to Reject the case if the counterparty does not know the competent institution which should handled the case?

As agreed, Reject will not be used.

Answer from Finland :

S045 in 5. Info on non-entitlement + other reason

Answer from France :

No need. There are options on S045 which can be used to reject the request made on S044

Answer from CZ :

We do not support this option, because this “rejection” SED in fact provides nothing more than horizontal information. H001 can serve the same purpose.

Remark received from UK

Should reject SED be allowed? Surely if the competent Institution is not known then it should be forwarded to Liaison

Office. Any other rejection covered by SED SO45 – reject not needed?

No action required

11/12/2015

H_BUC_01 should be available for Case Owner when receiving SED S045

Comment received from CZ :

It should be possible to start the horizontal process or sub process anytime throughout the whole BUC by every party. This allows counterparty to inform about its incompetence for proceeding of SED, or about probably more suitable institution. No other admin messages are needed.

Document updated

15/12/2015

Should the "invalidate" option be integrated in this BUC?

Comment received from FR :

Yes, if the process owner send S044 to an incorrect institution and would like to withdraw his request

15/01/2016

Section 3 "Actors and Roles"

Comment received from Germany about the reference to the "entitlement document" for both Case Owner and Counterparty:

'From my point of view SED S045 is NOT an entitlement document but a confirmation of entitlement. Having received S045 the IPS will issue a national entitlement document.

I am afraid S044, S045 as well as the Guidelines need to be adapted.'

04/01/2016

Question from Germany about section 5.2

Is this a regular section? I can’t see the advantage of having it here

This section is a global one and is used for all the BUCs.

No action.

15/01/2016

04/01/2016

Comment received from Germany :

I am not sure what “Identify all institutions from determined…” as there can only be one competent institution.

After “intermediate event” the question is missing to which the answer “yes” or “no” is given.

This sub-process is a general one and it gives the possibility to select at least 1 institution.

The question has been added after the "intermediate event"

Diagram has been updated

15/01/2016

12/01/2016

Section 3 "Actors and Roles"

Comment received from Belgium

If the competent MS is known, but not the exact competent institution, such a request should/can be sent to the liaison body of the competent MS.

Does the description of the concept “Counterparty” also cover the

liaison body or should it be explicitly mentioned?

Proposal: for reasons of clarity, BE prefers the explicit mentioning of the liaison body in the description of “Counterparty”.

21/06/2016

Conversion of the BPMN diagram to split between Case Owner and Counterparty.

Scheduled for update.

21/09/2016

AD_BUC_06_Subprocess – Invalidate SED should be added for the case owner - if the S044 was sent by mistake it have to

be possible to invalidate such message. If there is no option, the case is pending and stays active. This AD_BUC_06 should be used only before the reply on S045 is received. Because after that there is no point of invalidation.

This comment will be discussed during the AHG meeting the 4th October 2016.

Due to the fact that a negative answer is available in the

S045, AHG members suggest that Counterparty uses this negative answer to inform Case Owner that he/she made a mistake.

23/11/2016

21/09/2016

H_BUC_01 can only be invoked after step 8. In the other BUCs we have reviewed it has been moved to the beginning of the process for the case owner to be able to utilise H_BUC_01 at any point after they have sent the initial SED. We feel this should be replicated in the BUC.

This comment will be discussed during the AHG meeting the 4th October 2016.

AHG members agreed on your suggestion, the new version of the document has been updated according to your suggestion.

23/11/2016

21/09/2016

In this process there is no dispute functionality. Instead of starting the process again where for example, coverage was requested from 01/01/16 - 30/01/16 but the SO45 only starts from 08/01/16, the caseowner could send SO50, disputing the start date, perhaps attaching some supporting evidence for why it should be from 01/01/16. If the counterparty now agrees, they can send a new S045. Without the dispute loop, the case onwer needs to send a new request and start a new case in the application.

This comment will be discussed during the AHG meeting the 4th October 2016.

The S050 is used to dispute the date of registration or cancellation but not the entitlement document itself. If there is a mistake in S045, it can be fixed by H_BUC_01 or sending the request S044 again.

AHG members suggest in this case to start a new case.

23/11/2016

BPMN diagrams will be updated.

"Reminder" will be added for Case Owner

and Counterparty

Scheduled for update.