Lexipedia

EESSI Business Use Case

EESSI Business Use Case

S_BUC_12

Application for Cash Benefits Related to Incapacity for Work

S_BUC_12

Application for Cash Benefits Related to Incapacity for Work

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 14

4.3 Attachments Allowed 14

4.4 Artefacts used 15

5 Business Processes 16

5.1 Case Owner and Counterparty 16

5.2 Sub Processes 17

6 Appendices 18

6.1 Issues 18

Document Control Information

Settings

Value

Document Title:

Business Use Case

S_BUC_12 - Application for Cash Benefits Related to Incapacity for Work

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

01/03/2016

Valérie Banchereau

First draft of the document

v0.1.1

13/06/2016

Valérie Banchereau

Comments received from Germany, Belgium, United Kingdom and Finland have been implemented.

Section 3: Actors

Case Owner definition modified.

Section 4.1.: RUP Table description

Trigger modified

'Remarks' under Special Requirements has been moved after Step 5 of the Main Scenario.

Section 6.1 Issues has been completed with remarks / comments and answers received.

v0.2.0

23/08/2016

Valérie Banchereau

Alignment to the standard description and layout of the BUC.

Comments from Germany implemented.

Admins added : 'Reject', 'Forward' and 'Reminder':

- Section 4.1: RUP Table Representation adapted.

- Section 4.4: Use Case Diagram updated with new admins.

- Section 4.5: SED and Sub-process versioning table adapted.

- Section 5.1: BPMN diagram adapted with new admins.

v0.3.0

07/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.

v0.99.0

23/11/2016

Carine Molle

As agreed by AHG members : "Reminder", "Reject" and "Invalidate" will be added

Section 4.1 is updated

Branch 3 : "Reminder" is added for Counterparty

Branch 4 : "Reject" is added for Counterparty

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

30/06/2017

Joël Fiora

-Included BPMN picture in section 5

- removed Use Case diagram

v1.0.2

06/12/2017

Heidi Warson

- Included the latest version of the corresponding BPMN diagram in section 5

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 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 behaviors of the business system that the actor uses. 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 behaviors of the EESSI business system which will direct and govern part of the expected behaviors and functionality delivered by the EESSI IT System.

The business process models describe procedures of the EESSI business system. The subjects of these descriptions are interactions between actors and the business system, meaning the goods and services offered to customers and business partners. On the basis of business process models, outsiders can identify how to interact with the business system. They are especially useful to illustrate sequences, alternatives, and parallel events.

Scope

This document is limited to the external view of the Sickness' sector process concerning Application for Cash Benefits Related to Incapacity for Work. The different elements like use case description, business actors, and business process as well as supporting UML diagrams and BPMN models pertaining to the Application for Cash Benefits Related to Incapacity for Work.

Definitions, Acronyms and Abbreviations

Please see the EESSI Project Glossary here.

References

#

Description

1

EC Regulation 883/2004

Regulation EC No 883- 2004.pdf

2

EC Regulation 987/2009

Regulation EC No 987-2009.pdf

3

UML 2.x

http://www.omg.org/spec/UML/

4

BPMN 2.0

http://www.omg.org/spec/BPMN/index.htm

5

UML 2.0 In Action

Henriette Baumann, Patrick Grassle & Philippe Baumann, 2005, ISBN 1904811558

6

RUP@EC standard 5.0

http://www.cc.cec/RUPatEC_Standard/

7

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 Application for Cash Benefits Related to Incapacity for Work 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 Application for Cash Benefits Related to Incapacity for Work business process.

Chapter 4 describes in detail the Application for Cash Benefits Related to Incapacity for Work business process based on the RUP use case template, as well as the relationship to other use cases.

Chapter 5 describes the Application for Cash Benefits Related to Incapacity for Work business process using business process modelling notation (BPMN).

Description

Business Scenario

The purpose of this BUC is to transfer the medical certificate related to incapacity for work of the person concerned from the institution in the Member State of Residence/Stay to the competent institution.

This BUC is only relevant for cases where doctors in the Member State of Residence/Stay do not issue medical certificates for incapacity for work or are not in a position to issue such a certificate in a specific situation on the basis of national law, e.g. if the period for which the

medical certificate can be issued has expired.

An insured person requests a medical certificate for incapacity for work in his/her Member State of Residence/Stay where doctors, on the basis of national law, generally do not - or are not in a position to - issue such a certificate in his/her specific situation. This person shall turn to the institution of the Member State of Residence/Stay in charge of forwarding claims for cash benefits (medical certificates) to the competent institution.

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 articles providing the legal basis for each SED.

SED

Basic Reg. (883/04)

Implementing Reg. (987/09)

21

27(3)

27(8)

27(10)

S055

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 Member State of Residence / Stay that transfers a medical certificate related to incapacity for work to the competent institution.

Counterparty

In this BUC the Counterparty is the institution of the competent Member State for the insured person. The Counterparty receives the application for cash benefits for an insured person who is incapable for

work.

Table 2: Actors & Roles

Use Case

RUP Table Representation

Use Case ID:

S_BUC_12

Use Case Name:

Application for Cash Benefits Related to Incapacity for Work

Created By:

Valérie Banchereau

Last Updated By:

Carine Molle

Date Created:

01/03/2016

Last Revision Date:

23/11/2016

Actors:

Case Owner

Counterparty

Description:

In principle, in order to apply for cash benefits in respect of incapacity for work due to sickness, maternity or paternity, the insured person is obliged to submit the medical certificate issued by the doctor in the Member State of Residence/Stay directly to the competent institution.

If doctors in the Member State of Residence/Stay do not issue medical certificates for incapacity for work or are not in a position to issue such a certificate in a specific situation on the basis of national law (e.g. the period for which the medical certificate can be issued has expired), the institution of this Member State shall carry out a medical examination, issue a certificate and forward it to the competent institution.

Trigger:

An insured person turns to the institution of the country of residence/ stay in order to obtain a medical certificate on incapacity for work.

Preconditions:

The insured person resides or stays outside the Competent Member State.

This person is incapable for work due to sickness, maternity or paternity, but no medical certificate has been issued.

Post conditions:

The institution of the Competent Member State is informed about the application for cash benefits for incapacity for work due to sickness, maternity or paternity of the insured person.

Main Scenario:

Identify Participants

The Case Owner identifies the Member State competent to consider the

claim for cash benefits in respect of incapacity for work due to sickness or maternity/paternity;

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.

Send Request for Application for Cash Benefits

The Case Owner fills in the "Application for Cash Benefits" (S055) SED by entering all the required data;

Section 4 "Certificate of incapacity of work" is mandatory and must be filled-in with required data;

Section 4.1"The insured person mentioned above applied for

cash benefits on" is mandatory and must be completed with the date of insured person's request for cash benefits;

Section 4.2"Type of benefit" is mandatory and must be completed by selecting the appropriate checkbox;

Section 4.3 "Please find attached" is mandatory and must be completed by selecting the appropriate type(s) of document (a medical certificate, a medical report and/or other appropriate document);

Section 4.5 "According to the document mentioned above the person is incapable for work" is mandatory and must be filled in with the required information;

Section 4.5.1"From" is mandatory and must be filled with the date from which the insured person is declared incapable for work;

Section 4.5.2 "To" is optional but strongly recommended. The institution of the place of residence/stay should state the probable duration of the person's incapacity for work or state the reasons for which this is not possible in order to enable the competent institution to pay cash benefits;

Section 5 "Employer" should be filled in with all required information about the employer;

Section 5.3 "Employer's registered ID" is optional but strongly recommended to be completed, especially if the PIN of the person concerned is not available;

The Case Owner sends "Application for Cash Benefits" (S055) SED with attached medical certificate, medical report and/or other document to the Counterparty;

(the medical certificate sent in attachment is for example form E 116 or a Basic medical Report issued free of charge);

The Counterparty receives "Application for Cash Benefits" (S055) SED;

REMARKS:

If the incapacity for work lasts longer than the duration stated in the institution’s medical certificate attached to SED S055, a new SED S055 should be sent. The personal information contained in section 2 should be sufficient for the clerk to relate the first SED S055 to the subsequent ones. As an option, one may refer to the previous SED S055 or incapacity for work period in the additional information section.

The use case ends here.

Alternative Scenario:

The Following Branches Determine the use of Horizontal Processes within this Business Process

After [step 5] Counterparty may optionally choose to request Ad Hoc Information from the Case Owner.

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

[This Branch] Ends.

The Following Branches Determine the use of Administrative Processes within this Business Process

After [step 5] 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 order to receive the answer to Ad Hoc Information expected and not yet received.

The Counterparty executes business use case AD_BUC_07 – Reminder;

[This Branch] Ends.

After [step 5] Counterparty may optionally choose to notify the Case Owner that they Reject a SED they have received.

The Counterparty executes business use case AD_BUC_09 – Reject SED;

[This Branch] Ends.

at any step after [step 4] the Case Owner may choose to advise the Counterparty that their S055 is Invalid under Art 5 of 987/09

The Case Owner executes business use case AD_BUC_06 - Invalidate_SED;

Optionally, the Case Owner fills in an "Application for Cash Benefits" (S055) by entering all the required data;

Optionally, the Case Owner sends the S055, including any attachments, to the Counterparty;

[This Branch] Ends

Exceptions:

None

Includes:

See diagram at part 4.4

Special Requirements:

SR0: General Rule

As the Application for Cash Benefits Related to Incapacity for Work due to sickness, maternity or paternity is individualised, the case concerns 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 when the first SED is received by the 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

Following table specifies SED having logical pairing to one another, usually this is known as a request-reply pair.

REQUEST SED

REPLY SED(s)

None

None

Attachments Allowed

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

SED

Attachments

S055

Allowed

Artefacts used

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

Artefact name

Artefact type

S055

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 Application for Cash Benefits Related to Incapacity for Work.

Case Owner and Counterparty

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

1

29/02/2016

Actor Name: 'Claimant'. What about the claimant?

(See 'Trigger' part: 'this person shall turn to the institution of the Member State of residence or stay in charge of forwarding claims for cash benefits (medical certificates) to the competent institution '.

Should 'Claimant' be added as Actor, as there is an interaction between the insured person and the institution of the Member State of residence/ stay?

During the AHG meeting in November 2015 it has been decided to remove the claimant while the claimant does not play a role in the BUC.

But in the S_BUC_02 the Claimant is defined as an Actor of the BUC while the Claimant exchanges a portable document S1 with the Case Owner. When receiving the portable document, the Case Owner starts the BUC.

In S_BUC_12, the BUC starts because the insured person should obtain a medical certificate. The question is thus, should the claimant be added

in the BUC as an actor ?

Answer from Germany: Claimant could eventually be mentioned in pre or post conditions, especially when he uses a portable document. But it would be helpful to abstain from listing him as an actor under point 3.

2

29/02/2016

Section 4.3 of SED S055: Is it possible to tick more than one checkbox (e.g. tick 'Medical Certificate' and 'Medical Report')?

Answer from Germany: 'Yes'.

Will be handled in V4.0 of SED

06/06/2016

3

18/04/2016

Belgium comment on S055 Section 4.5.2: 'In our view, this should be parallel with the conditions for foreign incapacity certificates as imposed by articles 72 §1 and 2 (member states where medical doctors issue incapacity certificates).

As such, also in case of art. 27 §3, the institution of residence/ should always indicate the probable duration of the persons incapacity for work or state the reasons for which this is not possible.

As such, if the competent institution requests a new medical report afterwards, the control doctor of the institution should state the probable duration of the incapacity for work, as explicitly mentioned in art. 27 §5 Reg. 987/2009'

In V.4 version of SED S055, both start and end date will be mandatory.

Comment from Germany: From a German perspective this would be helpful. Yet, I am not sure whether all member states are able to fulfil this condition.

If not, the member states at stake could not send SED S055 anymore. As this SED is deemed to be used in countries where doctors do not issue certificates for incapacity to work, it will only be used be only a couple of process owners. It could be interesting to find out which countries would use it actively (the Netherlands would be one) and to ask them whether they are always able to fill field 4.5.2 before we make it mandatory.not, , the ising a secondary compulsory field out of it t. tions or postconditions, especially when th

06/06/2016

4

18/04/2016

Section 4.1 RUP table Description step 4;

Comment from Belgium on '(the medical certificate sent in attachment is for example form E116 issued free of charge)': Would this imply that the first E116 annexed to the S055 should always be free of charge, and that subsequent medical reports, if requested by the competent institution (art. 27 §5) can be charged (via H020 and H021)? (see also below in case of sending of new S055 in case of renewal of incapacity for work).

Cf. also wording of art. 87 §6 Regulation 883/2004 (examination made at request of the debtor institution)

Guidelines only mention E116 free of charge medical certificate (see p. 77). Loops are not accepted by Sickness Sector in this BUC. As S_BUC_12 only allows to deal with one S055 SED, the clerk should check if there is already one S055 for the person. If there were a possibility to send several S055 in one process (loop), it would be possible to bill from the second S055 on (see issue 6 above).

Could you explain what should be changed in the wording of this step ?

Answer from Germany: This is an interesting remark but I would not necessarily change the wording of Section 4.1.

I believe that we all agree that the question whether medical examination is free of charge or not mainly depends on the question whether it was explicitly requested by the competent institution or not. Formal aspects like the use of a certain SED or BUC should not blur this criterion.

06/06/2016

5

18/04/2016

Comment from Belgium on S055 section 5: Employer: 'this should only be mandatory if the person concerned has an employer. As such this field cannot be filled in when the person concerned is e.g. a self- employed residing outside the competent member state or

an unemployed person who becomes incapacitated for work during a temporary stay.

The modification in S055 will be handled with the version 4 of the SED.

Page 77 of the Guidelines should also be changed while it is written that 'Information about the employer is required because in particular cases it may be indispensable to identify the competent institution (e.g. if in a particular member state there is no central register of the insured person and/or if there is more than one

sickness insurance institution which may act as a competent institution.'

Answer from Germany: Would it be a solution if we would ask in the SED first if the person is employed or self-employed. If the person is

employed, the employer number should become compulsory (secondary compulsory field). As far as we know, it is an important issue for Poland.

06/06/2016

6

01/04/2016

Comment from United Kingdom: With the implementation of Reg 883/04 a person that has fallen sick in another member state should contact the competent institution at the outset of their incapacity. However these forms are still applicable as customers are in immediate need for cash assistance therefore they make their claim to the country of residence or stay.

No action needed

06/06/2016

7

26/05/2016

Comment from Finland: ' -Should BUC H001 be available in these BUCs (S_BUC_12, 14, 14a) also for PO (eg if clerk forget to attach a document to a given SED)? For example if clerk forgets to send attachments with S048, he/she could send them

afterwards with H001 or correct other mistakes or give additional information. Or is it intended that a new BUC should be started?'

Remark from Germany: This option is not open yet (see point 4.5). I believe we are waiting for feedback after the dry runs to integrate additional AD BUCs in Sickness BUCs, aren’t we?

Two solutions can be foreseen: either Counterparty sends H001 by using

H_BUC_01 requesting the missing attachments. The Case Owner replies by sending a H002 with the missing attachments.

Either, the Case Owner has the possibility to send an updated version of the S048 by using the "update" option (AC_BUC_10 - Update) available on the SED itself. The Case Owner creates a new version of the SED and has the possibility to send the attachments. The Counterparty will thus receive a new version of the SED, the previous

one will be inactivated but still available in the application.

This option should be available in next version, as well as 'Reject' and 'Clarify' (in Playground only, for testing). See EESSIDEV-4106

06/06/2016

8

12/05/2016

Section 4.1 RUP Table Representation

Special Requirements section: Comment from Germany (BO): 'From my point of view SR require that participants 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 themselves. It should probably be controlled at the national level application, but the rules should be described somewhere. This document captures this kind of requirements and behaviour.

06/06/2016

9

06/06/2016

Germany requests to add 'Reject' option after Counterparty receives a S055 SED which they can't deal with.

This is also an outcome of the DryRun workshop in Budapest end May 2016.

Section 4.1 RUP Table Description is updated

Section 4.4 RUP UC Diagram Representation is updated

Section 4.5 SED and Sub-process versioning is updated

Section 5.1 BPMN diagram is updated

07/06/2016

10

18.04.2016

Question received from Belgium regarding the following remark :

If the incapacity for works lasts longer than the duration stated in the institution's medical certificate attached to SED 055, a new SED S055 should be sent. The personal information contained in section 2 should be sufficient for the clerk to relate the first SED S055 to the subsequent ones. As an option, one may refer to the previous SED S055 or incapacity for work period in the additional information section

Question is whether in such case, the sending of the new SED S055 is made automatically, or whether the person concerned should make a new declaration with the institution of residence or

stay

RINA will not send automatically a new S055, this kind of solution should be implemented on national level and a new case should be created.

Another solution is to give the possibility to send a new S055. In this way, all the documents will be gathered in one single case.

What do you think about it ?

Answer from Germany: we wonder if it would not be a problem in order to find out when the case is closed/ is to be closed. Would it be an alternative to add a field in SED S055 in order to refer to evtl. Former SEDs S055?

23/08/2016

11

25/11/2016

BPMN diagram will be updated.

"Reminder" and "Reject" will be added for the Counterparty.

"Invalidate" will be added for the Case Owner

Scheduled for update.