Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
HTML Wrap
padding25px 50px 25px 50px
background-repeatno-repeat
margin0px 0px 25px 0px
source-page-id59192317
background-imageedel_banner2.png
classbanner--background
height200px
Section
source-page-id59192317
HTML
source-page-id59192317
<div class="banner--top-border"></div>
HTML Wrap
source-page-id59192317
classbanner

CEF DIGITAL

Working group meeting - APIs4IPS (API strategy essentials and REST-based API extensions and Blockchain) 

5 May 2020 / 09:30 - 12:30

Online meeting via Webex

Excerpt
hiddentrue
Page properties
Title

Working group meeting – APIs4IPS (API strategy essentials and REST-based API extensions and Blockchain) 

Excerpt

Working group meeting – focusing on the work on the future of eDelivery

Date

 

Event summary

The CEF eDelivery team is organising the first subgroup meeting focusing on the work on the future of eDelivery. This work will include a focus on REST-based API extensions to eDelivery and possible use of Blockchain technology.

If you have any additional comments or questions on the workshop, or generally concerning CEF eDelivery, the Service Offering or grant funding, please reach out to us via Service Desk.

Aui button
source-page-id59192317
TitleContact us
URLhttps://ec.europa.eu/digital-building-blocks/tracker/plugins/servlet/desk/portal/2/create/4

You will need to be logged in using an EU Login account to submit a request. Don't have an EU Login account yet? Sign up here.

 

Participants

:

European CommissionMember States' representatives
  • Bogdan Dumitriu (DIGIT D3) – Project Manager « eDelivery API extension »
  • Monica Posada (JRC B6) – Project Manager « API strategy essentials »
  • Dietmar Gattwinkel (DG CNECT H4) API4IPS coordinator
  • Andres Moreno (ECHA)
  • Fani Tsirantonaki (INEA)
  • Georges Lobo (DIGIT D2)
  • Ines Costa (DIGIT D3)
  • Lorenzino Vaccari (JRC B6)
  • Maarten Daniels (DIGIT D3)
  • Marcio Sampaio (DIGIT D3)
  • Mark Boyd (JRC B6 – external expert)
  • Radoslav Jakub (INEA)
  • Vlad Veduta (DIGIT D3)
  • Arne Tauber, Austria, EGIZ - eGovernment Innovation Center
  • Atte Pirttila, Finland, Digital and Population Data Services Agency
  • Daniel Lindbom, Sweden, Swedish Tax agency
  • Erik Hagen, Norway, DIFI - Agency for Public Management and eGovernment
  • Hans Sinnige, The Netherlands, RINIS Foundation
  • Jonas Žalinkevičius, Lithuania, eDelivery LT
  • Jose Antonio Eusamio, Spain, Ministry of Finance & Public Administration
  • Judie Attard, Malta, MITA - Malta Information Technology Agency
  • Klaus Luttich, Germany, Governikus
  • Manne Andersson, Sweden, Swedish eHealth agency
  • Martin Volcker, Sweden, DIGG, Agency for Digital Government
  • Marta Cruz, Portugal, AMA, Agency for Administrative Modernization
  • Michal Ohrablo, Slovakia, Office of the Deputy Prime Minister for Investments and Informatization
  • Michel Bugeja, Malta, MITA - Malta Information Technology Agency
  • Nicholas Chronopoulos, Greece, Ministry of Digital Governance
  • Pavel Tesar, Czech Republic, Ministry of Interior
  • Pedro Viana, AMA, Agency for Administrative Modernization
  • Petteri Kivimaki, NIIS - Nordic Institute for Interoperability Solutions
  • Piet van der Berg, The Netherlands, RINIS Foundation
  • Sven Rasmussen, Denmark, DIGST - Danish Agency for Digitalization
  • Tomas Sedivec, Czech Republic, Ministry of Interior
  • Ville Sirvio, NIIS - Nordic Institute for Interoperability Solutions
  • Virginijus Jasaitis, Lithuania, Ministry of Transport and Communications



Draft Agenda 

Item

Time

Who

PresentationsNotes

Welcome and introduction

15 mins

Dietmar Gattwinkel, DG CNECT H4

n/a
  • Dietmar Gattwinkel welcomed the participants and introduced the agenda for the session, asking participants whether any additions should be considered.

Presentation of JRC’s APIs4DGov study:

  • Outcomes and highlights of study
  • Objectives of upcoming study

25 mins

Monica Posada, JRC B6

  • Cf. slides.
  • Following the presentation, Martin Volcker asked what the role of the subgroup in the JRC work would be. Monica Posada clarified that this subgroup will be contributing to the work and that JRC would be consulting them. 

REST-based API extensions for eDelivery: How REST APIs can be used to support eDelivery in addressing specific use cases?

  • Timeline and methodology
  • Scoping concept

30 mins

Bogdan Dumitriu, DIGIT D3


Break

Brainstorm on possible use cases for REST-based API extensions for eDelivery based on input received from meeting participants

80 mins

Joao Rodrigues Frade, Bogdan Dumitriu, Maarten Daniels, Ines Costa, DIGIT D3

Meeting participants to contribute to the discussion

Cf. slides on previous point in the agenda.
  • Bogdan Dumitriu presented the approach to scope the exercise to define use cases for REST-based API extensions for eDelivery that would follow two possible directions:
    • Simplify the use of eDelivery
    • Expand eDelivery to support new message exchange patterns
  • Sven Rasmussen commented that the ‘publish / subscribe’ message exchange pattern could be ‘query’ in the UC1 on Patient Results, since sometimes the patient or GP does not need to be notified or even could not be notified as it is not known in advance. Accordingly, the ‘subscribe’ part would not apply. In a more general sense, the ‘query’ pattern could be understood as part of the ‘publish / subscribe’ pattern.
  • Andres Moreno (ECHA) stressed that the notifications via eDelivery would work in the context of a bigger hospital and that smaller institutions are not ready for eDelivery and would need to query data to a central platform. This is the case in the use case of ECHA’s Poison Notification Center where there is either an appointed body or the European Agency providing the database. Smaller institutions would have to query the European Agency database.
  • Bogdan Dumitriu asked RINIS to present the three use cases sent in advance of the meeting.
  • Hans Sinnige presented UC2 on Unemployment Benefits in the social security domain. This use case is based on an existing system, where information about the petitioner (the person who is claiming the benefits) such as the insurance record, salary details and family details need to be exchanged cross-border, so that the competent Member State can decide about a claim for unemployment benefits. In this case APIs could support the process to request information from a citizen in a ‘request/response’ message exchange pattern or even in a ‘Y/N query’ or ‘distributed query’ pattern to all MS. In variations of the use case, the question could also be sent to private institutions, such as insurance companies. This use case could be supported with AS4 but the use of APIs would speed up the request/response process. Party identification is important.
  • Maarten Daniels pointed out that this is an OOP use case. It could therefore also be D4All project exploring further advances for such scenarios. Related use cases are approached by ESSSI using AS4.
  • Gerard Soisson stated that there would be no problem in having a OOP use case covered in the SDG regulation since not all the procedures by the SDG regulation. It would positive to have more tools available for Member States to implement these use cases. The OOP system should not remain restricted to eDelivery, and the focus should be on developing as many tools as possible to use APIs in different message exchange patterns.
  • Sven Rasmussen agreed that APIs as an extension to eDelivery could be relevant in the long term to cover additional message exchange patterns and other use cases (e.g. for authorization and personal data, access to open data (simple or distributed query), etc.).
  • Michal Ohrablo agreed with Sven and Gerard by saying that this work is not a duplication. In the context of the preparation of SDG’s implementing act there are Working groups being formed by end of 2020. One of these Working groups will be focusing on the OOP architecture but there will be no time to go into details on standards and patterns supported. They will define and identify requirements for type of exchanges to be fulfilled by APIs, but these Working groups will not be able explore much further.
  • Hans Sinnige proceeded with presentation of UC 3 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; and also, UC 4 on Certificate of Education for exchange between institutions of higher education of certificates for completed or partially done studies. APIs could simplify this exchange, compared to using AS4. Use of AS4 in combination with Web services would make it hard to ensure a synchronous exchange and universities do not have easy access to AS4.
  • Maarten Daniels reassured that UC 4 is also in scope of the SDG regulation within the OOP system. Maarten informed that RINIS could contact their SDG National Coordinator to discuss this.
  • Martin Volcker insisted that there is a need for a new building block for REST APIs and synchronous exchange to support new message exchange patterns.
  • Sven Rasmussen reassured that there are a lot of possible use cases for REST APIs and that often what needs to be implemented depends more on the current situation and legacy. The focus should rather be on new message exchange patterns to support and on use cases for lightweight devices such as mobile phones. Both personal and non-personal data should be in scope. One extra tool available in the toolbox would support stakeholders to decide whether AS4 or APIs are covering the specific needs.
  • Dietmar Gattwinkel wrapped up the discussion and thanked the participation of the attendees.
  • Dietmar Gattwinkel informed that the purpose of this work is on creating guidelines facilitating the development of government API solutions in general. The use case to be chosen should therefore be regarded only as a first instantiation, und should be chosen pragmatically.
  • Martin Volcker asked for the subgroup to meet once a month and in having more people active in the work. Possibly a call for interest to have more people closely involved could be launched.
  • Dietmar Gattwinkel pointed out the subgroup will be asked to contribute to both the API Delivery extension pilot and the JRS Study on Government API strategy essentials, which will result in frequent meetings. In addition, as the objective is to conduct this work as collaborative as possible, collaborative spaces are available to the subgroup.
  • Bogdan Dumitriu insisted that would be relevant to think about why one would want to use REST API rather than AS4. Sven Rasmussen said that AS4 could be used for electronic registered delivery systems or for large files, for example, where the sender takes the initiative for the exchange.
  • Dietmar Gattwinkel wrapped up the discussion and thanked the participation of the attendees.

About the ISA² action on Innovative Public Services:

In the ISA² Work Programme for 2020, the action on Innovative Public Services 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.


About CEF eDelivery:

The CEF eDelivery building block helps public administrations and businesses (and indirectly citizens) to participate in eDelivery Messaging Infrastructures which facilitate organisation-to-organisation messaging by enabling their systems to interact with each other in a secure, reliable and trusted way. The Connecting Europe Facility (CEF) Digital Programme, is currently promoting the adoption of common standards in the eDelivery Messaging Infrastructures in different policy domains (Business Registers, eJustice, eProcurement, etc.).