Page History

HTML Wrap

background-color	#ececec
padding	20px
background-repeat	no-repeat
background-image	layers.png
background-position	right
class	aside--header aside--header__top-border

HTML
<span class="aside__top-border"></span>

Index of use cases

HTML Wrap

padding	20px
border-color	#ececec
border-width	2px
border-style	solid
class	aside--content aside__light-content

Table of Contents

HTML Wrap

background-color	#ececec
padding	20px
background-repeat	no-repeat
background-image	layers.png
background-position	right
class	aside--header aside--header__top-border

HTML
<span class="aside__top-border"></span>

Working group on APIs and Blockchain

HTML Wrap

padding	20px
border-color	#ececec
border-width	2px
border-style	solid
class	aside--content aside__light-content

The Informal Cooperation Network for eDelivery showed interest in exploring future developments that could be added into the eDelivery framework by leveraging on API and Blockchain related initiatives already in place across the Member States.

This page aims to collect use cases for REST-based API extensions for eDelivery that could serve as a basis to understand the possible upcoming developments to be undertaken by CEF eDelivery.

All members of the Informal Cooperation Network for eDelivery and Subgroup on future of eDelivery are invited to participate and provide their input by 22 May 2020

HTML Wrap

background-color	#ececec
padding	20px
background-repeat	no-repeat
background-image	layers.png
background-position	right
class	aside--header aside--header__top-border

HTML
<span class="aside__top-border"></span>

Background information

HTML Wrap

padding	20px
border-color	#ececec
border-width	2px
border-style	solid
class	aside--content aside__light-content

About the ISA² action on Innovative Public Services (future of CEF eDelivery):

For 2020, this action has, among others, the objective of developing relevant legal, organisational and technical artefacts trialled through an extension and combination of the CEF eDelivery building block with blockchain based transactions’ log and a REST-based profile (a.k.a. APIs approach), that support new patterns of data access by request and data sharing.

The work related to the REST-based profile will take as input the JRC study on APIs4DGov that analysed the API technological landscape and its standards and technical specifications for general purpose use. This aims to support the definition of stable APIs for digital government services, avoiding the need to develop ad-hoc solutions and helping stakeholders in the identification and selection of such solutions.

The scope of the ISA² action will be to develop the following:

A set of guidelines and specifications for establishing interoperable REST-based APIs for service invocation and publication of both open and protected data. Sample library implementation for API’s as well as software supporting central/core services such as service catalogues and service discovery could be also in scope.
Extension of eDelivery with other building blocks and innovative technical approaches such as blockchain and APIs. Should the pilots be successful, the CEF eDelivery building block will be enriched with a REST-based profile and a blockchain-based log of transactions. Every element will be modular so that it can be used in combination with the existing AS4-profile (of eDelivery) or on its own.

Info

title	How can I contribute?

You You can edit the page (CRTL+E or top right corner of the page) directly to add your use case(s) in the tables below.

In case you are not able to edit the page, you can also use the comments' box at the bottom of the page with the relevant information about your use case(s).

Please make sure to contribute by 22 May 2020.

Info

title	How can I comment on the existing use cases?

To To comment on existing use cases you can either use the in-line comments' function (select the text you want to comment and click on the comments' button), edit the page and contribute in the 'Discussion' section of the use case or use the comments' box at the bottom of the page for general comments.

Please make sure to comment by 22 May 2020.

Info

title	Information to provide about your use case(s)

When When providing information on your use case(s) please consider the following instructions for each section:

Title of UC	Please provide the title of the use case.
Description	Please describe the use case at a very high level, in one or two paragraphs.
Actors	Please highlight the actors that would consume eDelivery services in the realisation of the use case.
Purpose of communication	Please use notions such as ‘(Registered) data delivery’, ‘Publishing data’, ‘Querying data’, ‘Collecting data’, etc.
Message Exchange Pattern	Please use notions such as ‘Fire and Forget’, ‘Request / Response’, ‘Publish / Subscribe’, ‘Broadcast’, ‘Claim check’, ‘Distributed Querying’, ‘Y/N Querying’, ‘Collect’, etc.
Party identification	Is the identification of the parties to the communication required for both parties or just one (which)? The need should be understood to apply at the messaging layer, not at the application layer.
Non-repudiation	Is non-repudiation of the communication required?
Applicable limitation(s) of eDelivery AS4 profile	Please describe briefly the limitations of the eDelivery AS4 profile that you would like a REST-based API profile to address in order to better support your envisaged deployment.
Synchronous or asynchronous communication?	At a high level, is the nature of the communication synchronous or asynchronous?
Critical features required	Please consider aspects related to latency, power (resource) profile of the host platform – low-power, medium-power or high-power, or anything else critical for the solution to be applicable to the use case.
Contact point	Please provide your name and organisation.
Discussion	This aims to capture the discussions and comments by others on the use case.

HTML Wrap

background-color	#ececec
padding	20px
background-repeat	no-repeat
background-image	layers.png
background-position	right
class	aside--header aside--header__top-border

HTML
<span class="aside__top-border"></span>

Use cases

HTML Wrap

padding	20px
border-color	#ececec
border-width	2px
border-style	solid
class	aside--content aside__light-content

Please provide input on possible use cases for REST-based API extensions for eDelivery.

Use Case ID	UC 1 - Patient Results
Title of UC	*Distribution of patient results*
Description	Patient has investigations done at hospital (blood work, medical imagery, etc.). When the results are available, the hospital sends them to a central system, where they are made available for download on demand. The central system receives similar data also from other hospitals. When the patient goes to their General Practitioner’s (GP) office, the GP needs to be able to use their browser to retrieve the patient's results directly from the central system, without requiring the installation of additional backend systems. The patient can also retrieve the results using smartphone app. The authorisation to retrieve the results is granted based on the GP's or patient’s e-Identification.
Actors	Hospital, Central system, GP, Patient
Purpose of communication	Publishing data
Message Exchange Pattern	Hospital to central system: Fire and Forget. Central system to patient: Publish / Subscribe
Party identification	Hospital to central system: both parties need to be known. Central system to patient: only the sender needs to be identified. (Clarification: GP/patient eIdentification is considered as part of the payload.)
Non-repudiation	Not mandatory
Applicable limitation(s) of eDelivery AS4 profile
Synchronous or asynchronous communication?	Central system to patient: synchronous (i.e., the results should be provided on demand, not sent separately as a response to an earlier request)
Critical features required	Central system to patient: high level of security required, lightweight solution required for integration in browser / smartphone app, solution to run on medium- or high-power device.
Contact point	Sven RASMUSSEN DIGST (Danish Agency for Digitisation)
Discussion	UC mentioned by Sven RASMUSSENduring Event: Workshop#5 - Informal Cooperation Network for eDelivery

Use Case ID	UC 2 - Unemployment Benefits
Title of UC	*Exchange of information to determine a claim for Unemployment Benefits*
Description	This exchange is used to allow institutions in several Member States to exchange information about the petitioner (the person who is claiming the benefits) such as the insurance record, salary details and family details that the competent Member State needs in order to decide about a claim for unemployment benefits. The petitioners applying for unemployment benefits can be divided in normal workers in which case the petitioner claims the unemployment benefits in their state of last activity; and in cross-border workers in which case the petitioner can claim the unemployment benefits in the state of residence (article 65 of Regulation No 883/2004).
Actors	Institution of a Member State that is being petitioned by an unemployed person in order to determine the proper unemployment benefits.
Purpose of communication	Collecting Data
Message Exchange Pattern	Request/response
Party identification	Only certified parties are allowed to exchange this data, so both need to be identified
Non-repudiation	Not required
Applicable limitation(s) of eDelivery AS4 profile
Synchronous or asynchronous communication?	Synchronous
Critical features required	Low latency and secure
Contact point	Hans SINNIGE RINIS Foundation
Discussion	UC presented by RINIS Foundation during Subgroup Working group meeting - future of eDelivery (APIs4IPS (API strategy essentials and REST-based API extensions and Blockchain). This UC is being addressed in the work related to the Single Digital Gateway regulation within the Once Only Principle system. The work under this ISA² action is not aiming to duplicate the work done under SDG, but will extract all the relevant requirements stemming from this use case and use them as input in the development of a general-purpose REST API profile.

Use Case ID	UC 3 - Pension Supplements
Title of UC	*Exchange of pension amounts to determine supplements*
Description	This exchange is used to allow an institution in a Member State to ask a Competent Institution in another Member State for the amounts of the pensions paid by the other institution concerned, to check whether a supplement has to be granted. The institution concerned provides the information about the amount of a pension. It is usually used after the common pension claim procedure has been completed.
Actors	A Competent Institution who is institution of place of residence of the claimant.
Purpose of communication	Collecting Data
Message Exchange Pattern	Request/response
Party identification	Only certified parties are allowed to exchange this data, so both need to be identified
Non-repudiation	Not required
Applicable limitation(s) of eDelivery AS4 profile
Synchronous or asynchronous communication?	Synchronous
Critical features required	Low latency and secure
Contact point	Hans SINNIGE RINIS Foundation
Discussion	UC presented by RINIS Foundation during Subgroup Working group meeting - future of eDelivery (APIs4IPS (API strategy essentials and REST-based API extensions and Blockchain). This UC is being addressed in the work related to the Single Digital Gateway regulation within the Once Only Principle system. The work under this ISA² action is not aiming to duplicate the work done under SDG, but will extract all the relevant requirements stemming from this use case and use them as input in the development of a general-purpose REST API profile.

Use Case ID	UC 4 - Certificate of Education
Title of UC	*Exchange of certificates of education*
Description	In Europe it must be possible and made easy for students to study in different countries and even combine certificates of different schools or universities. Therefore it is important that schools and universities within Europe can easily and in a standard way access those certificates from other institutions.
Actors	A school or university with the consent of the student
Purpose of communication	Querying Data
Message Exchange Pattern	Request/response , Y/N querying
Party identification	The requesting party needs to identify itself
Non-repudiation	Not required
Applicable limitation(s) of eDelivery AS4 profile
Synchronous or asynchronous communication?	Synchronous
Critical features required	Low latency and secure
Contact point	Hans SINNIGE RINIS Foundation
Discussion	UC presented by RINIS Foundation during Subgroup Working group meeting - future of eDelivery (APIs4IPS (API strategy essentials and REST-based API extensions and Blockchain). This UC is being addressed in the work related to the Single Digital Gateway regulation within the Once Only Principle system. The work under this ISA² action is not aiming to duplicate the work done under SDG, but will extract all the relevant requirements stemming from this use case and use them as input in the development of a general-purpose REST API profile.

Use Case ID	UC 5 - provide your input here
Title of UC
Description
Actors
Purpose of communication
Message Exchange Pattern
Party identification
Non-repudiation
Applicable limitation(s) of eDelivery AS4 profile
Synchronous or asynchronous communication?
Critical features required
Contact point
Discussion

Use Case ID	UC 6 - provide your input here
Title of UC
Description
Actors
Purpose of communication
Message Exchange Pattern
Party identification
Non-repudiation
Applicable limitation(s) of eDelivery AS4 profile
Synchronous or asynchronous communication?
Critical features required
Contact point
Discussion

Use Case ID	UC 7 - provide your input here
Title of UC
Description
Actors
Purpose of communication
Message Exchange Pattern
Party identification
Non-repudiation
Applicable limitation(s) of eDelivery AS4 profile
Synchronous or asynchronous communication?
Critical features required
Contact point
Discussion

Space shortcuts

Page tree

Versions Compared

Old Version 29

New Version 30

Key

UC 1 - Patient Results

UC 2 - Unemployment Benefits

UC 3 - Pension Supplements

UC 4 - Certificate of Education

UC 5 - provide your input here

UC 6 - provide your input here

UC 7 - provide your input here