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
Background information
About the 2020 ISA² action on Innovative Public Services: Future of CEF eDelivery and API guidelines for government
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 as a candidate profile for future inclusion in CEF eDelivery, in order to support new patterns of data access and data sharing, 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 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.
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 .
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 .
Information to provide about your use case(s)
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.
Use cases
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
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
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
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 - 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
OOP TECHNICAL SYSTEM APPLICATION VIEW
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
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.
