Use cases for REST-based API extensions for eDelivery
Excerpt
Provide your use cases for REST-based API
Date
Status
Status
colour
Red
title
closed
Info
title
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 .
Info
title
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 .
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
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 2020 ISA² action on Innovative Public Services
(future
: Future of CEF eDelivery and API guidelines for government
This project is about the following specific activities (major outputs)
: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
Future of CEF eDelivery: extension of the CEF eDelivery building block with innovative technical approaches leveraging blockchain and REST APIs. This activity has the objective of developing and piloting relevant technical specifications and artefacts through the use by CEF eDelivery of a blockchain-based transactions’ log offered by the CEF EBSI building blocks, on the one hand, and the definition of a REST-based profile
(a.k.a. APIs approach), that
as a candidate profile for future inclusion in CEF eDelivery, in order to 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:
, on the other. Should the pilots be successful, the CEF eDelivery building block will be enriched with these novel technologies. Every element will be modular so that it can be used in combination with the existing eDelivery AS4 profile or on its own.
API guidelines for government: a set
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?
Login with your EU Login. Then, 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 .
Info
title
How can I comment on the existing use cases?
Login with your EU Login. 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 .
Info
title
Information to provide about your use case(s)
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.
Info
title
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
at the
metadata
messaging layer, not
to
at the
message payload
application layer.
Non-repudiation
Is non-repudiation of the communication required?
Applicable limitation(s) of eDelivery AS4 profile
Please describe briefly
why
the limitations of the eDelivery AS4
profile is not able to cover the use case requirements
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
Priority for low latency or high reliability and/or security? Is there a need for a lightweight solution? What is the
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
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.
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 This UC is being addressed in the work related to the Single Digital Gateway regulation in within 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 systemThe 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
Discussion let to the conclusion that this UC will be covered in the This UC is being addressed in the work related to the Single Digital Gateway regulation in within 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 systemThe 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. Therefor 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
Discussion let to the conclusion that this UC will be covered in This UC is being addressed in the work related to the Single Digital Gateway regulation in within 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.
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 - Data Management Interface
Title of UC
Data Management Interface for Central Repositories containing Public Administration (service) Metadata
Description
In many networks, including the Once-Only Principle (OOP) network in the context of the Single Digital Gateway Regulation (SDGR), Central repositories are used to retrieve metadata about Public Administrations and/or the services they expose to the network.
Specific examples for the SDG OOP network are the Data Service Directory (DSD), the Registry of Authorities (ROA) and the Criterion and Evidence Type Rule Base (CETRB).
These components typically have both an ad-runtime query interface and an ad-configuration data management interface. When these components are not decentralised across the participants in the network, but hosted centrally, e.g. at EU level, a data management interface is needed so the Public Administrations can create, update and delete the metadata.
Other examples for which a non-standardised data management interface already exists and that could potentially benefit from an update in a future version are the CEF eDelivery SMP and SML components.
OOP TECHNICAL SYSTEM HIGH LEVEL VIEW
Image Added
OOP TECHNICAL SYSTEM APPLICATION VIEW
Image Added
Image Added
Actors
Public Administrations, Central EU repositories
Purpose of communication
Publishing Data
Message Exchange Pattern
Publish
Party identification
Both parties need to be identified and known/configured beforehand.
Non-repudiation
Optional
Use Case ID
UC 5
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?
Synchronous
Critical features required
High level of security required
Lightweight solution required for integration in existing Public Administration services/components.
Contact point
Discussion
Use Case ID
UC 6 – FHIR pilot
Title of UC
Exchange of healthcare information using FHIR
Description
FHIR (Fast Healthcare Interoperability Resources) - https://www.hl7.org/fhir/ - is a REST based standard gaining traction in the health care domain. The specifications are well documented and structured and provide a practical instantiation to gain more experience with REST based APIs. This practical experience allows us to see what are the gaps and overlaps between REST APIs and eDelivery AS4. Additionally, this would allow us to widen our horizon and prepare for the forthcoming European Health Data Space (EHDS).
More specifically, the healthcare community itself is finding the right balance between the two approaches for secure and reliable healthcare data. For the moment the consensus seems to be that REST based protocols are best fit for data exchange between medical devices and/or within the same organisation, while SOAP based protocols are mainly used to exchange data between organizational boundaries.
Actors
Health care organisations, optionally including medical devices
Purpose of communication
Publishing data, Querying data, Collecting Data
Message Exchange Pattern
Request/response, Publish / Subscribe, Collect
Party identification
Only certified parties are allowed to exchange this data, so both need to be identified
Non-repudiation
Recommended
Applicable limitation(s) of eDelivery AS4 profile
Synchronous or asynchronous communication?
Synchronous
Critical features required
High level of security required
Lightweight solution required for integration in existing healthcare systems and/or medical devices.
