You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 36
Next »
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 | |
---|
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 | |
---|
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 | |
---|
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 | |
---|
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 ![](/digital-building-blocks/sites/download/attachments/232688667/High%20Level%20overview.jpg?version=1&modificationDate=1593427386808&api=v2)
OOP TECHNICAL SYSTEM APPLICATION VIEW
![](/digital-building-blocks/sites/download/attachments/232688667/Application%20view.jpg?version=1&modificationDate=1593427428079&api=v2)
![](/digital-building-blocks/sites/download/attachments/232688667/image2020-6-17_16-2-4.png?version=1&modificationDate=1592402537101&api=v2)
|
---|
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. |
---|
Contact point |
|
---|
Discussion |
|
---|
Use Case ID | |
---|
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 |
|
---|
|