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
How can I contribute?
You can edit the page (CRTL+E or top right corner of the page) directly to add your use case(s) in the table 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 .
How can I comment on the use cases?
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) or the comments box at the bottom of the page.
Please make sure to contribute by .
Background information
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.
Use cases
Please provide input on possible use cases for REST-based API extensions for eDelivery.
Instructions on how to introduce your Use cases
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 to the metadata, not to the message payload.
Non-repudiation
Is non-repudiation of the communication required?
Applicable limitation(s) of eDelivery AS4 profile
Please describe briefly why the eDelivery AS4 profile is not able to cover the use case requirements
Synchronous or asynchronous communication?
At a high level, is the nature of the communication synchronous or asynchronous?
Critical features required
Priority for low latency or high reliability and/or security? Is there a need for a lightweight solution? What is the power (resource) profile of the host platform – low-power, medium-power or high-power?
Contact point
Please provide your name and organisation
Discussion
This aims to capture the discussions and comments by others on the use case
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.
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
Discussion let to the conclusion that this UC will be covered in the Single Digital Gateway regulation in the Once Only Principle system. Some members of the network further commented that there is no harm in focusing as well in developing a solution to address this UC on top of what will be discussed and developed under the OOP system.
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
Discussion let to the conclusion that this UC will be covered in the Single Digital Gateway regulation in the Once Only Principle system. Some members of the network further commented that there is no harm in focusing as well in developing a solution to address this UC on top of what will be discussed and developed under the OOP system.
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. Therefor 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
Discussion let to the conclusion that this UC will be covered in the Single Digital Gateway regulation in the Once Only Principle system. Some members of the network further commented that there is no harm in focusing as well in developing a solution to address this UC on top of what will be discussed and developed under the OOP system.
Discussion let to the conclusion that this UC will be covered in the Single Digital Gateway regulation in the Once Only Principle system. Some members of the network further commented that there is no harm in focusing as well in developing a solution to address this UC on top of what will be discussed and developed under the OOP system.