Pending EC approval - e-SENS | Moving services forward! · SWOT...

Pending EC approval

D3.3 Report of integrated view of LSP sustainability strategies 1

Submitted to the EC on 27/03/2014

COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME ICT Policy Support Programme (ICT PSP)

Project acronym: e-SENS

Project full title: Electronic Simple European Networked Services

ICT PSP call identifier: CIP-ICT-PSP-2012-6

ICT PSP main theme identifier: CIP-ICT-PSP-2012-6-4.1 Basic Cross Sector Services

Grant agreement n°: 325211

D3.3 Report of integrated view of LSP sustainability strategies

Deliverable Id : D 3.3

Deliverable Name : Report on the integrated view of LSP strategies

Version : V1.0

Status : Draft

Dissemination Level : Public

Due date of deliverable : M 6

Actual submission date : 27.03.2014

Work Package : WP 3

Organisation name of lead partner for this deliverable : OpenPEPPOL AISBL and DIGST

Author(s):

Anni Buhr (DIGST, DK), Carmen Ciciriello (OpenPEPPOL), Katrin Weigend (BVA,DE), Roberto Zuffada (LISPA, IT), Aleida Alcaide (MINHAP, ES), Carmen Cirnu (ICI, RO), Lara van Riet (ICTU, NL), Lefteris Leontaridis (MAREG – UPRC, GR), Anders Kingstedt (ESV, SE)

Partner(s) contributing : Freek van Krevel (MINEZ, NL), Sven Rasmussen (DIGST, DK), Jack Verhoosel (TNO, NL), Isabella Rapisarda (Consip, IT)

Pending EC approval


Abstract

The work carried out in e-SENS is based on the results of the previous five Large-Scale Pilots (LSPs), which were launched by the EC for the following different domains:

eID (STORK)

eProcurement (PEPPOL)

Business Start-up (SPOCS)

eHealth (epSOS)

e-Justice (e-CODEX)

As well as considering the technical solutions, e-SENS also considers the sustainability plans of the LSPs in order to create a consolidated sustainability concept.

This report:

Presents a consolidated view of the different sustainability strategies & plans developed by the five LSPs.

Summarising the plans, noting synergies across them, related barriers – and potential counter approaches for overcoming such barriers.

Pending EC approval


History

Version Date Changes made Modified by

0.09 15.09.2013 Consolidating input received by D.3.3 authors for Chapter 2

Carmen Ciciriello

0.1 14.10.2013 Consolidated version including input received by authors for Chapter 3

Carmen Ciciriello

0.2 18.10.2013 Consolidating feedback received from WP3 manager and reviewers

Carmen Ciciriello

0.3 24.10.2013 Consolidating feedback received from WP3 members

Carmen Ciciriello

0.4 1.12.2013 Consolidating feedback received from external Quality Review and WP3 members

Carmen Ciciriello

0.5 3.12.2013 Consolidating feedback received from WP3 Manager

Carmen Ciciriello

0.6 23.12.2013 Restructure the deliverable based on GOA (Governance, Operations and Architecture) and moving LSP plans to annex

Anni Buhr (The D3.3 team)

0.7 20.1.2014 A draft with the restructured report including contributions to all chapters except conclusion and executive summary


0.8 29.1.2014 Revised based on comments from the D3.3 team


0.9a 21.2.2014 Final revised version ready for external quality review

Anni Buhr

0.9b 24.02.2014 Check final revised version Freek van Krevel

0.9c 25.03.2014 Final revised version after 2nd

review Anni Buhr

1.0 27.03.2014 Final editorial amendments WP1

This deliverable contains original unpublished work or work to which the author holds all rights except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

Pending EC approval


Table of contents

History ..................................................................................................................................................... 3 Table of contents ..................................................................................................................................... 4 List of Figures ........................................................................................................................................... 5 List of Tables ............................................................................................................................................ 6 List of Abbreviations ................................................................................................................................ 7 Executive Summary ............................................................................................................................... 12 1. Introduction .................................................................................................................................. 15

1.1. Scope and Objective of Deliverable ..................................................................................... 15 1.2. WP3 and Task 3.3: General Objectives and Vision .............................................................. 15 1.3. Methodology of Work .......................................................................................................... 15 1.4. Relations to Internal e-SENS Environment .......................................................................... 17 1.5. Relations to External e-SENS Environment .......................................................................... 17 1.6. Quality Management ........................................................................................................... 18 1.7. Risk Management ................................................................................................................ 18 1.8. Legal Issues .......................................................................................................................... 19 1.9. Structure of the document .................................................................................................. 19

2. Overview of LSP Sustainability Plans ............................................................................................ 20 2.1. PEPPOL ................................................................................................................................. 20 2.2. SPOCS ................................................................................................................................... 24 2.3. STORK and STORK 2.0 .......................................................................................................... 26 2.4. epSOS ................................................................................................................................... 28 2.5. e-CODEX ............................................................................................................................... 31

3. Integrated view of LSP Sustainability Plans .................................................................................. 35 3.1. Governance .......................................................................................................................... 35 1.1. Operations ........................................................................................................................... 40 1.2. Architecture ......................................................................................................................... 43

4. Conclusions and Recommendation .............................................................................................. 46 4.1. Conclusions .......................................................................................................................... 46 4.2. Recommendations ............................................................................................................... 47

4.2.1. Governance ................................................................................................................. 48 4.2.2. Operation .................................................................................................................... 48 4.2.3. Architecture................................................................................................................. 49 4.2.4. Re-use, take-up and continued support...................................................................... 49

5. References .................................................................................................................................... 51

Pending EC approval


List of Figures

Figure 1 OpenPEPPOL headlines for the GOA model ............................................................................ 23 Figure 3: SPOCS headlines for the GOA model ..................................................................................... 26 Figure 4 STORK headlines for the GOA model ...................................................................................... 28 Figure 5: epSOS headlines for the GOA model ...................................................................................... 31 Figure 2 e-CODEX headlines for the GOA model ................................................................................... 34 Table 6: Governance incl. stakeholder per LSP ..................................................................................... 38 Table 7: High-level BBs developed per LSP ........................................................................................... 43

Pending EC approval


List of Tables

Table 1: Abbreviations ........................................................................................................................... 11 Table 2: Quality Checklist ...................................................................................................................... 18 Table 3: Risks ......................................................................................................................................... 19

Pending EC approval


List of Abbreviations

Acronym Explanation

AB Architectural Board

ABB Architectural BB: Specifications and Standards (specifications) of BBs

AISBL Association Internationale Sans But Lucratif : it refers in this document to the OpenPEPPOL AISBL (international NPO)

ASIC-S Associated Signature Container, which is a data container holding a set of data objects and associated signatures within a ZIP file. ASiC-S is the first type of a container and a simple container to associate one or more signatures with a single data object.

BB Building Block: it represents a (potentially re-usable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions.

BIS Business Interoperability Specifications

BOMOS Beheer en Ontwikkelmodel voor Open Standaarden (Management and Development Model for Open Standards)

BSCW Basic Support for Cooperative Work

CA Contracting Authority

CC Coordinating Communities in OpenPEPPOL

CCBE Council of Bars and Law Societies of Europe

CCTS Core Component Technical Specification re UN CEFACT activities

CEF Connecting Europe Facility

CEN BII

CEN UBL

European Committee for Standardization - Business Interoperability Interfaces

Universal Business Language

CIP Competitiveness and Innovation Framework Programme

CONNECT [Directorate General] for Communications Networks, Content & Technology that manages the digital agenda of the European Commission.

Continua

Continua Health Alliance is an international non-profit, open industry group of nearly 240 healthcare providers, communications, medical, and fitness device companies. Continua Health Alliance members aim to develop a system to deliver personal and individual healthcare.

CNUE Council of the Notariats of the European Union

CSP Core Service Platform

D3.4 Deliverable 3.4 “Preliminary proposal for a governance body”

DB Domain Board

Pending EC approval


DBX OASIS BusDox Technical Committee - where BusDox is the name of the specifications submitted for standardization by PEPPOL on the Transport Infrastructure

DG Directorate General of the European Commission

DIGIT Directorate-General for Informatics

DSI Digital Service Infrastructure

DSS Digital Signature Service

EEA European Economic Area

EC European Commission

e-CODEX e-Justice Communication via Online Data Exchange

EC sustainability study

“The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots,

including ‘ex-ante’ evaluation (SMART 2012/0059). This study was carried out by Deloitte for the European Commission. In D3.4 and D3.5 this was abbreviated “the Deloitte study”.

eIDAS Draft Regulation "on electronic identification and trusted services for electronic transactions in the internal market"

eHGI eHealth Governance Initiative

eHN eHealth Network

EIF European Interoperability Framework

EO Economic Operator

eP ePrescription

epSOS Smart Open Services for European Patients

e-SENS Electronic European Networked Services

eSIgn/eIDCC e-Signature/e-ID Coordinating Community (OpenPEPPOL)

ETSI European Telecommunications Standards Institute

EU European Union

EUGO All national PSCs are part of the European EUGO network

EUROJUST

Agency of the European Union dealing with judicial co-operation in criminal matters. The seat of Eurojust is in The Hague.

EXPAND CIP/PSP Thematic Network, deploying sustainable cross-border eHealth services in the EU / expanding Health Data Interoperability Services.

See http://www.expandproject.eu

FWA Framework Agreement

Pending EC approval


HBB High Level BB: it is an aggregate of ABBs and related Assets/Artifacts.

ICT Information and Communication Technology

ICT PSP Information and Communication Technology Policy Support Programme (part of CIP)

IDABC Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens

IHE Integrating the Healthcare Enterprise

ISA Interoperability Solutions for Public Administrations: is a European Commission Programme that sets out to improve and facilitate efficient and effective cross-border electronic collaboration between European Public Administrations at different levels of government.

ITIL Information Technology Infrastructure Library

JUnit Unit testing framework for Java

LCM Life Cycle Management

LOINC Logical Observation Identifiers Names and Codes

LSP Large Scale Pilot

MS Member State

NA National authorities

NCP National Contact Point

NGO Non-governmental organisation

NPO Non for Profit Organisation

OASIS Organisation for the Advancement of Structured Information Standards

OCD Omnifarious Container Format for e-Documents

OCSP The Online Certificate Status Protocol is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track.

PEPPOL Pan-European Public Procurement Online

PEPS Pan European Proxy Service

PoACC Post-Award Coordinating Community (OpenPEPPOL)

PRACC Pre-Award Coordinating Community (OpenPEPPOL)

PS Patient Summary

PSC Point of Single Contact

PSB Project Steering Board (epSOS)

Pending EC approval


QAA Quality of Authentication Assurance Model

RACI Responsible, Accountable, Consulted and Informed

SAML Security Assertion Mark-UP Language

SANCO Health and Consumers Directorate General (DG SANCO)

SBB Solution BB: Sample Design and/or Software Component that is an implementation of (part of) an ABB. A sample Design and/or Software Component is conformant to (part of) the ABB specification

SEMIC.EU Semantic Interoperability Community

SDO Standardisation Organisation

SLA Service Level Agreement

SME Small and Medium-sized Enterprises

SML Service Metadata Locator

SMP Service Metadata Publisher

SP Service Provider

SPOCS Simple Procedures Online for cross-border Services

SPOCS TL SPOCS Trusted List

STORK/STORK 2.0 Secure Identity Across Borders linked

SWOT Strengths/Weaknesses/Opportunities/Threats: a SWOT analysis is a tool that supports planners in identifying the areas where they should focus by using a framework of internal Strengths and Weaknesses and external Opportunities and Threats.

TA Technical Annex e-SENS Technical Annex v3.0

TC Technical Committee

Ten-Tele Regulation

Regulation of the European Parliament and of the Council on “Guidelines for trans-European telecommunications networks” (part of the CEF)

TFEU Treaty on the Functioning of the European Union

TICC Transport Infrastructure Coordinating Community (OpenPEPPOL)

TL Trusted List

TSL Trusted Service List

UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business

V-IDP Virtual Identity Provider

VCD Virtual Company Dossier

WP e-SENS Work Package

Pending EC approval


WP3 e-SENS Work Package 3 “Sustainability and Long-Term Governance”

WP4 e-SENS Work Package 4 “Project Legal Expertise Centre”

WP5 e-SENS Work Package 5 “Piloting”

WP6 e-SENS Work Package 6 “Building Block Provision”

Table 1: Abbreviations

Pending EC approval


Executive Summary

The e-SENS (Electronic Simple European Networked Services) project focuses on strengthening the Single Market by facilitating and promoting interoperable public services across borders based on the results of the existing LSPs: PEPPOL, e-CODEX, STORK, epSOS and SPOCS.

The technical BBs developed and piloted by the LSPs will be consolidated, improved and extended in e-SENS. This also requires a stable consolidated sustainability plan.

The goal of e-SENS Work Package 3 is to pave the way for the sustainable usage and long-term governance of the LSP BBs, (and thus also their interoperability), within all European Member States and Associated Countries. WP3 therefore presents proposals for sustaining the e-SENS BBs (e-ID, e-Signatures, e-Documents, and e-Delivery), that have emerged from the LSPs.

The overall objective of Task 3.3 is to produce a holistic sustainability and governance model1 for the short, medium and long-term. Task 3.3 focuses on designing governance for sustainable BBs by defining strategic and policy recommendations for governance models with the aim to increase take-up by the market. This will be done in more steps:

1. Investigate the sustainability strategies produced by the existing LSPs.

2. Assess different governance models taking into account the EC sustainability study and by

consulting various and different stakeholders.

3. Recommend a holistic governance model for the short, medium and long term.

The objective of this document is to provide a consolidated view of the different sustainability strategies and models developed by the five LSP projects, i.e. to scrutinise each LSP’s approach to sustainability and long-term governance, and try to deduct common approaches.

The main conclusions are that the common denominators of the LSP sustainability strategies are relatively limited, because the explanations for each of the parameters (governance, operation and architecture) vary across the respective LSPs. These parameters were chosen to ease the alignment with the study “The feasibility and scenarios for the long-term sustainability of the LSPs, including ‘ex-ante’ evaluation” by the EC (hereinafter EC Sustainability Study) that uses the GOFA model – Governance, Operation, Financing and Architecture. As this report is not addressing financing issues, the “F” has been left out.

When assessing the existing and previous LSPs, the following findings can be summarised:

Governance plans are not aligned. At present, the governance structure ranges from a working governance model for OpenPEPPOL (a public-private NPO) all the way to project solutions in epSOS and e-CODEX that are limited to the duration of the project, i.e. no sustainable governance in place.

Regarding operations, DG DIGIT under the ISA Programme is a common operational partner in three of the LSPs (e-CODEX, OpenPEPPOL and STORK). epSOS seems to diverge from this model with the launch of the EXPAND project that is not run under DG DIGIT, and has instead been set-up by DG CONNECT to secure the eHealth assets and bridge from epSOS to CEF2.

1 Holistic as it should describe the wholes and not “just” separate parts.

2 http://www.expandproject.eu/

Pending EC approval


From an architectural point of view, the solutions designed by the LSPs have partly been developed in isolation. Only e-CODEX and SPOCS have tried to re-use technical standards from other LSPs. However, all LSPs are based on international standards. So far, an overall common approach to architecture has been lacking which means that re-use of BBs has been very limited.

Turning to market take-up, PEPPOL (the only LSP to do so) has implemented its components in several countries with increased volumes of transactions3. Overall, PEPPOL is by far the most mature LSP in terms of take-up by the market.

The overall recommendation from the present investigation is threefold:

Strategically an in depth-analysis of stakeholders is needed. Focusing on a greater diversity of stakeholders, e.g. end-users, service providers, IT industry etc.

From a governance perspective, a flexible multi-level organisation seems to be necessary in order to be able to take on board very different stakeholders.

On the operational side, it is recommended to ensure there is a common process for life cycle management as this is one of the key factors for market take-up. A mature life cycle management process has been set up by OpenPEPPOL.

Regarding architecture, attempts have been made to reuse BBs from one LSP to another, however little re-use has actually taken place, apart from in SPOCS and STORK 2.0.

o SPOCS has used the eID BB from STORK and both the Virtual Company Dossier and the e-Signature validation from PEPPOL.

o STORK 2.0 has used the PEPPOL e-Signature validation.

Re-use is central to the reasoning for launching e-SENS, i.e. consolidate – improve – extend. The task to secure the architectural convergence belongs in Work Package 6.

In the long term the e-SENS BBs are intended to move from public funding towards self-sustainability by themselves, i.e. that the BBs are taken up by the market.

A point for specific attention is the development of a coherent vision for the consolidation of high level BBs. At present, the LSPs are working hard to sustain their individual solutions, either through the ISA Programme4 or through for example the OpenPEPPOL organisation. At the same time, the CEF Work Programme5 is focusing on the deployment of BBs produced by some of the LSPs. From which it follows there is the risk that multiple versions of the same high level BBs (DSI)6 are deployed throughout Europe, before e-SENS has the chance to consolidate these BBs. So, one recommendation could be to focus on the Architectural BBs underlying the high-level e-SENS BBs

3 http://project.peppol.eu/pilot-reporting

4 http://ec.europa.eu/isa/

5 http://ec.europa.eu/digital-agenda/en/connecting-europe-facility

6 http://ec.europa.eu/dgs/connect/en/content/public-services-digital-service-infrastructures-connecting-

europe-facility

http://project.peppol.eu/pilot-reporting

Pending EC approval


(eID, e-Signatures, e-Documents and e-Delivery) during the first couple of years in the CEF Work Programmes.

This document will form one of the pillars for the next steps for Task 3.3.

Pending EC approval


1. Introduction

1.1. Scope and Objective of Deliverable The scope of this deliverable is to consolidate the different sustainability plans developed by the five LSP projects. The LSPs supported by the European Commission had as their objective to develop basic solutions for several different domains: eID (STORK/STORK2.0); eProcurement (PEPPOL); Business Start-up (SPOCS); eHealth (epSOS) and e-Justice (e-CODEX). In order to draft this deliverable the individual approaches to sustainability and long-term governance will be studied and common approaches will be deduced. Here special attention is drawn to (re e-SENS Technical Annex, p. 64):

Re-use of BBs

Uptake in market

Willingness to continue support

“The added value of this task is to conclude how the sustainable models of the individual large-scale pilots can be used in combination with each other with a view to the Digital Internal Market and how to overcome the barriers.”7

So, the overall goal is to synthesise the different existing sustainability models of the LSPs by scrutinising them and extracting their commonalities and differences. Apart from the three aforementioned attention points listed in the TA, the attention is drawn to governance, organisational and architectural approaches and to identify omissions in the current LSP sustainability plans. The points for attention listed in the TA (re-use, take-up and continued support) will be handled under architecture, operations and governance respectively.

1.2. WP3 and Task 3.3: General Objectives and Vision The e-SENS Work Package 3 (WP3) ‘Sustainability and Long-Term Governance’ concerns the long-term consolidation and maintenance of the technical solutions developed within e-SENS. The goal of Work Package 3 is to pave the way for sustainability and long-term governance of the e-SENS BBs and their support in creating interoperable public services across all European Member States and associated countries.

The objective of Task 3.3 in Work Package 3 is to design the governance and the sustainability models of the e-SENS BBs, defining scenarios and recommendations for their further take-up and acceptance.

1.3. Methodology of Work Experts with a background from all LSPs were selected to take responsibility for gathering related information on sustainability plans.

Initially, the most mature and comprehensive plans which came from PEPPOL and SPOCS were used to derive the initial sustainability dimensions for the analysis.

7 e-SENS Technical Annex v3.2, p. 64

Pending EC approval


A matrix template was developed and populated with a series of data from each LSP in order to gather the key information required to derive the most relevant content from an extensive set of LSP sustainability documents. The matrix format ensured that the information gathering process has been carried out systematically. Moreover, the matrix provided the authors of this deliverable with a summary cross-LSP view of the synergies and gaps in the various sustainability approaches. These dimensions were used for the collection of input to get an overview of the sustainability planning in the various LSPs.

e-SENS TA requires that the authors take the EC sustainability study into account and build upon its results in Task 3.3; and after an in-depth assessment of the methodology used within it, the authors agreed to use the same methodology that it used. Hence, this document takes on board the main elements to consider for sustainability, namely Governance, Operations, Financing and Architecture. However, as the Technical Annex does not mention financing as part of Task 3.3, and as financial aspects will be dealt with by Task 3.4 “Common Business Case” it was decided to leave out any financing aspects in the present analysis.

The financial aspects of e-SENS sustainability will be addressed in Task 3.4 that will elaborate on the business case of the BBs as well as in the next deliverable of this Task 3.3, the D3.6 “Scenarios for governance models on short, medium and long-term”. In the long run, financing cannot be split from governance, i.e. according to the English idiom “He who pays the piper calls the tune”.

The requirement to address continued support, take-up by the market and re-use of BBs (special attention) maps very well to the sustainability dimension in the EC sustainability study.

This leaves us in the present analysis with a GOA model:

Governance addresses the decision-making process, stakeholder involvement and legal aspects. Including willingness to continue support.

Operations addresses what a future support system would look like, how and where BBs/components are maintained – and how the BBs are taken up by the market.

Architecture addresses questions related to developed components, artefacts and modules; and how reusability, design (central/de-central) and evolution of the components are planned in relation to sustainability. So, this includes the notion to re-use BBs.

Some of the concepts used in this report are explained below to ensure the following chapters and sections are understood.

Sustainability

“Sustainability” in the e-SENS context means to guarantee the usage of the BBs of e-SENS after the project’s lifetime. This implies in particular long-term planning, a governance structure to ensure maintenance of methodologies, data models, specifications as well as software components. Furthermore deploying, running and disseminating the solutions within an organisational structure are crucial for sustainability.

Governance

This deliverable defines “Governance” as the management of sustainability. That means: How can sustainability be managed and achieved in an organisational structure? What legal impact could this have? Governance is seen as the structure that ensures control and steering, i.e. who decides on what and who is consulted? This means that governance is concerned with decision-making and how

Pending EC approval


the decisions are executed, for both strategic and operational decisions. This involves coordination and management of stakeholder’s interests.

Governance does not include development of legal frameworks and regulations, this must – of course – be determined through the usual channels (The Council of the European Union and the European Parliament).

Maintenance

Activities necessary for the upkeep and continuous upgrade of the BBs upon completion of the e-SENS project. In other words, how is the evolution of the e-SENS BBs ensured?

GOA model

This model derives from the EC sustainability study model GOFA, where financing has been left out:

Governance: decision making and stakeholder involvement

Operation: how is the day-to-day operation of the solutions run? Who supports the solution and how changes are handled.

(Finance: how is financing organised and governed.)

Architecture: which BBs are used, how they are structured8?

1.4. Relations to Internal e-SENS Environment Synergies between Task 3.3, Task 3.5 and Task 3.2 were identified at an early stage while preparing this deliverable and led to a high level of cooperation between the task leaders through coordination of cross-over activities, contributing to the key findings and identifying barriers and synergies from both operational and technical perspectives. There is a strong relationship with Task 3.4, so that it can take-up the financial aspects, as soon as it starts its work.

In particular, close cooperation between Task 3.3 (which focuses on the governance design) and Task 3.5 (which focuses on the governance implementation aspects) was established. The role of the Task 3.2 leader was to provide feedback on technical and operational dimensions for the sustainability of the BBs.

The relevant stakeholders within e-SENS (such as the Domain Board and Architectural Board) liaised through the meetings, conference calls and dedicated workshops that were established and maintained to ensure further consensus and consistency of results.

WP4 will deal with the legal issues:

Addressed by the LSP sustainability plans

In the recommendations from the EC sustainability study.

1.5. Relations to External e-SENS Environment On-going cooperation has been established with representatives from the LSPs but apart from this, no external cooperation has been established. 8 http://ec.europa.eu/digital-agenda/en/news/final-report-study-feasibility-and-scenarios-long-term-

sustainability-large-scale-pilots

Pending EC approval


1.6. Quality Management

Category Remarks Checked by

Conformance to e-SENS template

OK Anni Buhr

Language & Spelling OK Anni Buhr

Delivered on time No, postponement agreed with WP1. New delivery date March 2014

Freek van Krevel

Each technology description contains the correct elements

OK Freek van Krevel

Consistency with description in the TA and in other e-SENS deliverables

OK Freek van Krevel

Contents are fit for purpose

OK Anni Buhr

Contents are fit for use

OK, will be used internal in WP3 for the D3.6 deliverable

Anni Buhr

Commitment within WP

OK, supported by the previous and current LSPs

Freek van Krevel

Table 2: Quality Checklist

1.7. Risk Management

Description Probability Impact Priority Response Owner

Unexpected loss of the technical experts required to validate specific concepts and content within the Deliverable – due to availability issues.

Medium High High Additional resources were added to the team

WP3 leader, T3.3 leader

The integrated view will not be fully compliant with all LSP sustainability plans

High Medium Medium Mitigated by having all LSPs being able to find themselves in the integrated view somewhere.

WP3 leader, T3.3 leader

Limited resources and time against

High high high Prioritisation of the tasks and responsibilities, which

WP3 leader, T3.3

Pending EC approval


high expectations and unforeseen work

need to be carried out leader

Contributions by the partners are not delivered in time/the deadlines are not met

medium high medium Controlling timeline and reminding the partners to meet the deadlines/ monitoring the delivery

T3.3 leader

Contributions by the partners do not have the sufficient quality and quantity

medium high high Monitoring of the development process of the deliverable and iterating the document. Be clear on expected input.

T3.3 leader, WP3 leader

Analysis of the given information is not detailed enough

medium high high Drafting a table of content and formulation of guidelines and expectations


Content not fit for purpose

High Medium High The whole deliverable was restructured


Table 3: Risks

1.8. Legal Issues One aspect of sustainability is the legal aspect under the governance dimension. Legal issues are described in this deliverable corresponding to how they were dealt with in the LSP sustainability plans. However, further elaboration on legal challenges will be addressed in WP4 and to some extent in D3.6 Scenarios for governance models on short, medium and long-term.

1.9. Structure of the document The document is structured into 4 chapters as follows:

Chapter 1 describes the motivation for drafting the deliverable, defines how the work was planned and completed, and the detailed methodology it followed. It describes where the work fits in relation to other tasks in WP3, and the liaisons with other work packages of the e-SENS project. Chapter 1 also presents any risks of the work performed and how they were mitigated.

Chapter 2 provides a summary view of how each of the five LSPs have defined and approached sustainability, focusing on governance, operations and architecture.

Chapter 3 provides an integrated view on the sustainability plans, a synthesis of the common denominators of the LSP sustainability plans as well as elaboration of the special attention points: Market take-up, re-use of BBs and willingness to continued support.

Chapter 4 presents conclusions and recommendations based on the findings gathered in Chapter 3.

The annex provides a glossary and list of figures and tables.

Pending EC approval


2. Overview of LSP Sustainability Plans This chapter provides a summary of the sustainability plans of each LSP.

The LSP overviews are based on the GOA model, as described in 1.3 “Methodology of Work” on page 15, including a first section describing the vision of the LSP. The following sections will be presented per LSP:

Objective: Introduction to the LSP: the acronym explanation, its high level objective and some general points for the implementation.

Governance: A brief explanation about the underlying rationales for the preferred governance structure is given, e.g. supervision and the steering of the decisions of the LSP project including the roles of the stakeholders are given.

Operations: A brief explanation about the day-to-day running of the technical solutions and the final implementation is given based on the requirements.

Architecture: A brief explanation about the components identified and developed in the LSP, the architectural approach and to a brief extent its potential re-usability is given.

2.1. PEPPOL

Objective

The PEPPOL project (Pan-European Public Procurement On-Line, 2008-2012) was launched to address the key eProcurement challenges in Europe. Its objective has been to enable businesses to communicate electronically in the procurement process with any European government institution, increasing efficiencies and reducing costs.

PEPPOL was based on the “connect once, communicate everywhere” principle and did impose not design / infrastructure / access restrictions on service provider and end users, but instead left those decisions (if desirable) to the market and the member states.

PEPPOL aims to reduce the cost and complexity of implementing eProcurement solutions based on one set of standard specifications and to facilitate supplier access to a wider eProcurement market across borders.

Governance

PEPPOL ended in August, 2012, but during the last year of the project it set up a Long-Term Sustainability Team that established OpenPEPPOL, a follow-up organisation that took over the PEPPOL BBs, operations and governance from September 1st, 2012. That legal entity took the form of an international association NPO under Belgian law and it is based in Brussels.

OpenPEPPOL has engaged, (through direct membership or joint initiatives and regular consultations), its entire set of relevant stakeholders:

Pending EC approval


The main users of PEPPOL-enabled systems and services: Contracting Authorities and Economic Operators.

Commercial service providers which facilitate access to the PEPPOL infrastructure.

Institutional stakeholders, responsible for policy setting and implementation.

Standardisation Organisations which provide technical standards used by PEPPOL.

The European Commission and its relevant policy and operational units.

The governance structure of OpenPEPPOL consists of the following units and bodies:

The General Assembly, composed of all Members;

The Coordinating Communities, which are clustered around specific subject areas (Transport Infrastructure, Post-award, Pre-award, e-Signatures/eID);

The Managing Committee;

OpenPEPPOL is a members-driven organisation. According to its Statutes, which are published on the internet9, the membership categories include all relevant stakeholder groups. The General Assembly is composed of all the OpenPEPPOL Members and represents the highest decision-making body, as the supreme power of the Association. All Members have a vote, and therefore individual stakeholders are directly involved in all the main decisions concerning OpenPEPPOL. From January 29th 2014, the private sector has had a seat on the OpenPEPPOL Managing Committee and therefore co-decides, (and not simply cooperates), with the public sector.

Most of the day-to-day decisions and the executive responsibility of implementing the decisions of the General Assembly lie with the Managing Committee. The composition of the Managing Committee includes representatives of four Coordinating Communities, which are explained below. These Communities ensure that relevant stakeholder groups to those communities are represented at the executive layer of governance. The General Assembly can also elect up to two additional Managing Committee members, thus providing one more mechanism for stakeholder influence on decision-making that directly affects governance.

Sustainability is ensured by the fact that the OpenPEPPOL Association is self-funded through the fees paid by its members, thereby ensuring that there is sufficient critical mass of interested implementers who are willing to support the governance organisation. As PEPPOL is running an e-Delivery infrastructure that has already passed the mark of a million transactions, a sound organisational basis through OpenPEPPOL is important. The legal basis through the Transport Infrastructure Agreement framework provide an anchor for the entire implementation community and provide the credibility that is needed for the public bodies and industry stakeholders that invest in the implementation of PEPPOL-enabled solutions.

Operations

The maintenance of the PEPPOL BBs, components and specifications is made by member groups which are clustered in four Coordinating Communities, The four Coordinating Communities (CCs) are:

Transport Infrastructure Coordinating Community (TICC)

Post-Award Coordinating Community (PoACC)

Pre-Award Coordinating Community (PrACC)

9 http://www.peppol.eu/about_peppol/openpeppol-statutes/statutes-for-openpeppol-aisbl/at_download/file

http://www.peppol.eu/about_peppol/openpeppol-statutes/statutes-for-openpeppol-aisbl/at_download/file

Pending EC approval


e-Signature/e-ID Coordinating Community (eSIgn/eIDCC)

There are purpose-specific Working Groups within these CCs which are responsible for particular areas of specifications and components. All WGs in all CCs are following commonly agreed procedures for change management, release management and support. In the case of the PEPPOL infrastructure, change management is made jointly with DG DIGIT, which in turn is responsible for Release Management.

The OpenPEPPOL infrastructure is used by thousands of end-users through the 90 members of OpenPEPPOL with a high-volume of transactions.

The OpenPEPPOL software is all based on open source and available on JoinUp10.

Architecture

PEPPOL has focused on the critical phases of eProcurement, developing specifications – PEPPOL Business Interoperability Specifications (BIS) – to implement standards-based solutions, interoperable across Europe. In particular, PEPPOL offers:

Validation of eSignatures issued by certificate authorities;

a Virtual Company Dossier to request and submit standardised company information and mutually recognised evidence (certificates and attestations), based on existing standards (CEN/BII and UBL);

eCatalogues to request, submit and exchange information about goods and services in a standardised format;

eOrdering and eInvoicing using a defined set of processes to share common business information.

The PEPPOL e-Delivery network (Transport Infrastructure and Agreements for network governance) interconnects eProcurement communities using common standards (OASIS DBX Technical Committee). Access to the PEPPOL network is made possible through gateways called Access Points, which can be and currently are provided by both public and private service providers. The PEPPOL Architecture is decentralised as components are deployed close to the business partners, typically over a 4-corner model topology11 in post award and in e-Signature validation. In the four-corner model communication takes place between two Access Points, which can be offered by two service providers, respectively for the sender and the recipient organisation. There are certain central components, which are not hubs or portals, but only provide auxiliary services such as routing, discovery and semantic mapping.

10

https://joinup.ec.europa.eu/software/peppol/home 11

http://www.peppol.eu/news/news_repository/four_corner_model_v1.jpg/view

Pending EC approval


Figure 1 OpenPEPPOL headlines for the GOA model

Governance

Operations

OpenPEPPOL: a member-driven self-funded NPO

All stakeholder groups eligible as fee-paying members are represented in the General Assembly, the decision-making body of OpenPEPPOL

Architecture

Based on existing standards: e-Delivery -> OASIS dbx TC, and BIS and VCD -> CEN/BII and UBL

De-centralised architecture with light central components in some subject areas

Four corner topology “connect once, communicate everywhere”

Infrastructure used by thousands of end-users through the 90 members of OpenPEPPOL

OpenPEPPOL CCs provide Change and Release Management jointly with DG DIGIT

e-Delivery infrastructure with high-volume transaction loads

Pending EC approval


2.2. SPOCS Objective

Businesses seeking to expand into other countries often struggle to comply with all the regulations they need to follow. Applying for licenses permits and completing other administrative procedures in another country can be very time consuming. SPOCS12 aimed to overcome these obstacles by providing seamless electronic procedures and by building cross-border solutions based on each of the EU country’s existing systems.

The scope of the SPOCS project is aimed at building the second generation Point of Single Contact (PSC) through the availability of high impact electronic procedures, stimulating innovation and competitiveness through the wider uptake and best use of ICT by citizens, governments and businesses, including small and medium sized enterprises (SMEs). The aim of SPOCS was to develop an interoperability layer to foster the services economy in Europe by facilitating the service providers to apply via the PSC for businesses that the EU MSs have set up. Therefore, the aim of the pilots was to show that the BBs developed within the SPOCS project composing this interoperability layer indeed do function in a real life environment.

Governance

The SPOCS solutions, that were technically complete at the end of the project in December 2012, require further piloting and additional work in order to align with national solutions. While a governance model has not been set-up, a SPOCS Interoperability Group has been established where pilots have agreed on a structure to continue building on their cross-border interoperability experiences within e-SENS, DG MARKT's EUGO13 and other initiatives. The expansion of SPOCS solutions to other professions and PSCs requires a serious and coordinated effort for PSCs and CAs - and their administrative and technical resources. To move forward with this, SPOCS made a proposal to DG MARKT’s EUGO network, as it would be the most relevant platform to coordinate future action. Along these lines, resources must focus on organisational, policy and semantic interoperability - requiring analysis and negotiation. The technical level can be addressed in e-SENS but other collaborative European initiatives will be needed on the administrative aspects. Operations

In line with the European Interoperability Framework (EIF)14, SPOCS addressed the legal, organisational, semantic and technical issues, focusing on two main operational aspects:

1. Related to sustainability of the BBs and,

12

http://www.eu-spocs.eu/ 13

http://ec.europa.eu/internal_market/eu-go/index_en.htm: The PSCs are e-government portals for entrepreneurs active in the service sector. It is a legal requirement to have a PSC in each EU country since December 2009 as set out in the EU Services Directive. EU countries are not legally obliged to make available tax and social security procedures through the PSCs. However, a large number of EU countries already provide for this possibility, and all others are encouraged to do so too. All national PSCs are part of the European EUGO network. PSCs allow to find information about the rules, regulations and formalities that apply to service activities or to complete the administrative procedures online (by submitting the necessary application forms and supporting documents etc. electronically). You no longer have to go to the individual offices of different authorities in different countries, one by one. In each EU country, applications can now be dealt with online through one single access point, the PSC.

14

http://ec.europa.eu/idabc/en/document/2319/5644.html#what

http://ec.europa.eu/internal_market/eu-go/index_en.htm

Pending EC approval


2. The infrastructure and lifecycle management of the pilots.

The SPOCS Sustainability Task Force looked at fostering further adoption, use, and longevity of the software modules, specifications, guidelines, and other assets with technical sustainability being a key focus. In terms of objectives of adoption/ take-up in the short-medium-long term, eight of the nine pilots are live online in PSC environments in Austria, Germany, Greece, Italy, Lithuania, Poland, Portugal and Slovenia. Romania realised the need to upgrade their national PSC-service to complete the integration of SPOCs modules. In Greece the SPOCS solutions at the central PSC are being used to connect different regional agencies, Italy is looking at extending to the regional PSCs. Half of the piloting countries are planning to use SPOCS in other un-piloted professions.

The documentation of the SPOCS project is made freely available and accessible through the SPOCS website which provides a wide range of user-documents, specifications and the SPOCS Starter Kit, and through the JoinUp platform15. Software life-cycle management and coordination should be organised in e-SENS. SPOCS planned to establish a service and maintenance organisation with an underlying financing/business model for central BBs such as the SPOCS Trusted List (TL) and upper ontologies along with the lifecycle management of the converged BBs, through the e-SENS project.

Architecture

The SPOCS architecture has taken sustainability into account by developing decentralised BBs which are listed below. This allows for a large variety of infrastructures and deployment scenarios. This was proven by the SPOCS pilot deployment in nine different national infrastructures. The BBs have been designed for generic use case scenarios and can also be deployed in other areas where semantic equivalence (of documents) and/or safe and secure electronic transport are at stake. Most of the activities related to the further use and development of the BBs will be carried out in the e-SENS project.

The BBs developed by SPOCS are:

eServices & Syndication

e-Delivery

e-Documents

eSafe

SPOCS Trusted Service List (TSL)

The SPOCS BBs are based on Open Source and available in JoinUp

15

https://joinup.ec.europa.eu/software/spocs/home

http://www.eu-spocs-starterkit.eu/architecture

Pending EC approval


Figure 2: SPOCS headlines for the GOA model

2.3. STORK and STORK 2.0 Objective

STORK16 (Secure idenTity acrOss boRders linKed) is an initiative that helps to ensure the EU wide interoperability of ICT-based solutions where secure identity is an important element of the solution.

STORK establishes a European eID Interoperability Platform that enables citizens to securely use their national electronic identities in any Member State for public eGovernment services. The use of eID across borders is in conformance to relevant data protection and privacy legislation. The STORK project finished in December 2011.

The STORK 2.017 project started in June 2012 to contribute towards and facilitate the creation and take-up of a single interoperable and sustainable electronic identification (eID) authentication area for Europe, for legal and natural persons, building on the results of STORK. The initiative will drive convergence between the private and public sector, at national and EU level, for secure and easy access to cross-border public services using eID credentials.

16

https://www.eid-stork.eu/ 17

https://www.eid-stork2.eu/

Governance Operations

No establishment of a concrete SPOCS governance model

A SPOCS Interoperability Group has been established

DG Markt and EUGO Platform e-SENS

Architecture

Decentralised architecture based on national interfaces SPOCS BBs based on Open Source

Software life cycle management should be organised and coordination is needed.

Starter Kit/JoinUp

SPOCS Sustainability taskforce has addressed the legal, procedural, organisational, semantic and technical issues

Pending EC approval


Governance

Currently the Governance of STORK results have been taken up by the ISA programme18 as the organisation that would assume responsibility for the maintenance and updates of the common specifications and common software reference modules.

ISA included in their work programme an action that aims to guarantee the technical sustainability of the STORK platform. This action will update the common specifications and the QAA (Quality Authentication Assurance) model developed in STORK. It will upgrade and maintain software modules supporting common functionalities of the cross-border infrastructure as well as architectural issues.

Member States will be part of a committee created by ISA to take part in the decision-making process referred to as the STORK Member State Reference Group. However, it is expected that the future governance of the STORK results will be considered when implementing the eIDAS Regulation19.

For the sustainability of the STORK solutions, industry is seen as an essential partner.

Operations

In the future, user requirements will be taken into account by ISA where a governance model will be established where all MS can participate. As part of the governance structure, communication channels will be established. This enables requests for changes or for upgrades. Once endorsed and approved by the MS steering committee, the requests will be taken up by the EC technical team in order to update the BBs accordingly. Moreover, user requirements are being collected through the various pilots that are part of the on-going STORK 2.0 project.

STORK identified the need for strong central engagement by the EC to support the solution. ISA action for STORK sustainability will provide the technical support to the MS for the BBs and reference implementation for SBBs. However, it is envisioned that some type of support (not yet decided) should be provided by the national experts in charge of running the local STORK infrastructures.

Architecture

STORK components are the following:

STORK ABBs would be: SAML2.0 Profile, Personal Identity Attributes, QAA Levels, OCSP Profile

STORK SBBs would be: PEPS, SP Integration Package, V-IDP and OCSP Software

STORK has a decentralised architecture based on local technology nodes (PEPS or V-IDP) in the participating countries. There is no central technological hub. The PEPS communicate among themselves using the Internet as communication carrier. This is made possible based on an agreement on the use of certain protocols and standards – particularly, the eID solution created by the STORK project that has already been successfully re-used by several of the LSPs as SPOCS. The

18

https://www.eid-stork.eu/index.php?option=com_content&task=view&id=306&Itemid=69 19

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0238:FIN:EN:PDF

Pending EC approval


software for the common modules for a PEPS and Member States implementations (BBs) are based on open source and available at the JoinUp portal20.

Figure 3 STORK headlines for the GOA model

2.4. epSOS Objective

Implementing cross-border service in the eHealth domain, epSOS21 (Smart Open Services for European Patients) focuses on improving medical treatment of citizens while abroad by providing health professionals with the necessary patient data in a secure electronic format. epSOS aims to offer seamless healthcare to European citizens by building and evaluating a service interoperable infrastructure. The epSOS LSP provides an ideal opportunity to test the extent to which the quality of unplanned care (that is entitled to in accordance with the rules on citizen mobility in Regulation (EC) 883/200422 and Directive 2011/24/EU23), can be improved by timely access to patient summary data and electronic prescriptions.

20

https://joinup.ec.europa.eu/software/stork/home 21

http://www.epsos.eu 22

Regulation (EC) 883/2004 of the European Parliament and of the Council of 29 April 2004 on the

coordination of social security systems.


ISA Programme to lead the STORK results + MS in the decision-making proces

Regulation on eIDAS is required to implement the eID solution in a pan-European framework

The industry is essential for the sustainability of the STORK solutions

Architecture

Decentralised architecture based on local technology nodes

STORK ABBs and SBBs base don open source and available in JoinUp: high level of reusability

Strong central engagement of the EC to support the solution

New user requirements come from STORK 2.0

Strong steering of the public sector to ensure take up the results

Pending EC approval


Governance

Both the Project Steering Board (PSB, the highest project governance body composed of representatives of MS health authorities) and the EC have converged on the priorities in epSOS. The PSB engages Member States (MS) and industry in addressing common interoperability challenges in Europe and benefitting from common EU level development. This is done to accelerate national eHealth deployment, solving common challenges, including legal barriers (i.e. data protection, privacy and confidentiality, liability, safety and security) through implementing the common epSOS cross border pilot. Recent EU legislation24 - currently transposed or under transposition at MS level – provides a legal framework confirming the role of the Union in supporting the collaboration among MS through a voluntary mechanism, networking authorities responsible for eHealth. According to the subsidiarity principle, an eHealth Network (eHN) of NAs has been established under DG SANCO. eHN is supported through an open process of coordination by the eHealth Governance Initiative (www.ehgi.eu)25. In addition to this, epSOS governance – the PSB - has dealt with the liaisons between the NAs and competence centres with IHE and SDOs establishing a mechanism for the adoption of documents built according the international standards.

The epSOS NCP is an organisation as far as the legal and regulatory aspects are concerned. It creates the conditions (by supporting trust, data protection and privacy) for a trusted relationship with other countries’ epSOS NCPs, i.e. the epSOS countries that have signed the epSOS framework agreement which is the initial basis for the trusted relationship among the epSOS national authorities (the Ministries of Health). When the epSOS project finishes, there will be no legal basis anymore.

The epSOS NCP refers to more levels:

A legal organisation based on an epSOS framework agreement.

An operating unit, the epSOS support organisation, that is responsible for operating the services and

The technical gateway (“software”)

Operations

epSOS implementation strategy is designed according to guiding principles including:

The joint development of the common EU level concepts and specifications are in line with co-ordinated EU and national policies emerging from the eHealth Governance Initiative and the directions of the PSB. EU policy actions have been incorporated in epSOS policies, priorities and use case descriptions, including the proper use of common terms. Activities implemented by the epSOS national teams - from requirements definition to localisation of the operation and piloting - ensure shared ownership of the common developments and well informed implementation at national level.

23

Directive 2011/24/EU of the European Parliament and of the Council of of 9 March 2011 on the application

of patients’ rights in cross-border healthcare. 24

Art. 14 (1) of the Directive 2011/24/EU on the application of patients’ rights in cross-border healthcare. 25

http://www.ehgi.eu

Pending EC approval


A technical coordination to safeguard the integration of the epSOS interoperability specifications spanning across all four interoperability areas: legal, organisational, technical and semantic.

The development of concepts and descriptions of common epSOS services that represent international workflows and require agreements on organisational matters (i.e. privacy, safety and quality of services) facilitated through a dedicated policy and strategy task in the project.

epSOS secures sustainability through both the engagement of industry and of MS administrations through encouraging market development and services adoption by industry and national administrations.

The quality and acceptability of the deliverables of the epSOS LSP is guaranteed by the proper involvement of relevant experts from all MS to contribute, comment and verify the content of common EU level technical work thus ensuring openness, transparency and validation of the process.

epSOS NCPs are organisations delegated by each Participating Nation, acting as an interface between the existing different national functions provided by the national IT infrastructures and those provided by the common European infrastructure, created in epSOS.

The epSOS NCP takes care of external and internal national communication. It can be regarded as the support organisation within epSOS that for example handles the semantic mapping of codes and translations between the different coding systems and languages.

The epSOS NCP is operated nationally (de-centrally) in the epSOS participating countries. epSOS central services are run jointly by the epSOS consortium by a contract with a supplier.

The EXPAND project (Expanding Health Data Interoperability Services)26, started on January 2014 for a duration of 24 months. It has the goal of consolidating and disseminating epSOS assets, enriching them with contributions from other projects on semantic interoperability, creating the eHealth domain bridge to CEF. However, the legal sustainability of the epSOS Framework Agreement after the project has ended is not addressed in EXPAND.

Architecture

epSOS cross-border technical interoperability is based on the definition of the epSOS Interoperability Architecture, developed in the form of the detailed technical specification of the NCP-to-NCP interfaces, protocols and profiles. These interfaces are compliant to international standards.

epSOS has adopted IHE27 profiles which shall be continued in order to safeguard project and MS investment by national authorities responsible for the NCP infrastructure and its reliability. epSOS provides guidelines of possible NCP software architecture, including the definition of the interface between NCP and national infrastructure to help MS in their implementation.

The epSOS solution BBs are these: Patient Summary, ePrescription & eDispensation, Consent Service, Terminology Service Access Manager, Identification Service, Standards and Specifications and Common Code.

26

http://www.expandproject.eu/ 27

IHE Europe is a NPO dedicated to interoperability in health information technology, IHE-Europe gathers a

broad range of stakeholders to advance the shared exchange of patient information (http://www.ihe-europe.net).

Pending EC approval


epSOS BBs of the OpenNCP toolkit, are made available as Open Source through JoinUp.

Figure 4: epSOS headlines for the GOA model

2.5. e-CODEX

Objective

e-CODEX means “e-Justice Communication via Online Data EXchange”28. The objective of e-CODEX is the improvement of the cross-border access of citizens and businesses to legal means in Europe as well as the improvement of the interoperability between legal authorities within the EU29. In this regard the broader vision of e-CODEX is that any citizen and/or legal professional in Europe can communicate in a secure and trustworthy manner with any legal authority. This approach also includes the communication and exchange of information between legal authorities.

28

For more information: http://www.e-codex.eu/home.html 29

e-CODEX, D1.12 ’Sustainability Plan“ (update of D1.7)


MS and EC deciding and converging on common interoperability challenges

Synergies with eHGI and eHN

Organisation of the health service in MS applying the subsidiarity principle

Industry committment in accelerating eHealth deployment

Architecture Building on and compliant to IHE profiles and SDOs

standards (HL7)

NCP Software Architecture including the definition of the interface between NCP and National Infrastructure helping implementation in MS

Responsibility of national authority through reliability of the NCP infrastructure

Maintenance and integration of the epSOS specifications across interoperability areas

Open Source community on JoinUp: Software Development Consortium as a basis for eHealth Software Solutions

Pending EC approval


e-CODEX is still in progress and expected to end in 2015. Sustainability aspects are currently under discussion within this LSP

30. Therefore the information indicated in this section need to be considered as preliminary.

Governance

The stakeholders, who will represent the judicial domain or cross-domain will decide on the goals and objectives which should be achieved by deploying the cross-border public services. These could for example be the European Commission, the Member States (e.g. Ministries of Justice; directly or via the Council Working Party e-Justice/e-Law), standardisation organisations, the IT-Industry and the end-users - courts, citizens and legal professionals (lawyers, notaries, judges, public prosecutors etc.).

The responsibilities and tasks within a future governance structure, which could be carried out by those entities are still under discussion and not defined yet. At the tactical level, the stakeholders will determine the way the service is operated and what standards and techniques shall be used. On the operational level, stakeholders will have to periodically agree on what is supported by the services and which use-cases will be carried out.31 The Ministries of Justice within the Member States and the National Computing Centres under the control of these Ministries have a prominent role and need to be involved in the decision-making process. Furthermore, the EC is an important stakeholder, who needs to be involved since DG Justice is running the European e-Justice Portal, to which the e-CODEX solutions will be connected to and DG DIGIT is also hosting parts of the e-CODEX infrastructure32. The feedback and expert knowledge of the IT industry and the end users is valuable as well. To this end, a governance model needs to be established which takes into account the needs and requirements of the different stakeholders33. The sustainability plan of e-CODEX states that involvement of the EC and standardisation organisations will be decided in the future.

Different regulations, directives, decisions and studies are having or will be having an impact on the sustainability of the results of e-CODEX and should be taken into account, e.g. the future update of the e-Justice action plan34 or the “The study on the analysis of the Needs for Cross-Border Services and Assessment of the Organisational, Legal, Technical and Semantic Barriers”35. Operations

The e-CODEX methodology defines the necessary process that can be applied whenever a Member State or an Associated Country decides about new applications of the e-CODEX infrastructure. Additionally, the data model developed in the context of e-CODEX that describes the data transmitted can be used in a variety of different contexts inside the area of e-Justice.

30 There are sequentially planned updates of the e-CODEX sustainability plan which will lead to a detailed and concrete sustainability concept at the end of the project.

31 e-CODEX D1.12 “Sustainability Plan” (update of D1.7), Chapter 4.1.1

32 e-CODEX is a decentralised system. Data exchange is done between e-CODEX gateways. DG DIGIT will be

hosting the e-CODEX gateway which is going to connect the e-Justice Portal to other e-CODEX gateways hosted by the Member States. 33

First ideas and intentions about a future governance structure can be found in e-SENS D3.4 “Preliminary

proposal for a governance body”33

on page 45 ff. 34

Current version: Multi-Annual European e-Justice Action Plan 2009-2013 (2009/C 75/01) 35

http://ec.europa.eu/digital-agenda/en/news/final-report-study-analysis-needs-cross-border-services-and-

assessment-organisational-legal

Pending EC approval


The components need to be hosted in a central repository in the future. Currently JoinUp36 is used, where two software components37 have already been published.

Within the e-CODEX infrastructure there are some components that need to be hosted and maintained at European or central level (e.g. gateway and connector for the European e-Justice portal), whereas other components will be hosted in the Member States (e.g. national connector)38. These will be mapped in the sequentially planned updates of the e-CODEX sustainability plan. The collection of user requirements - based on the specifications of the national infrastructures - is handled via the tool-based change management system called JIRA39. These requirements are collected by the parties responsible for the integration of the e-CODEX solutions into their national infrastructure. In order to improve the e-CODEX pilots and the quality of the technical solutions, numerous feedback loops take place throughout the piloting phase. Software components created by e-CODEX need to be made available in a central repository and maintained by an organisational unit, which could be established by the Member States and Associated Countries. This will ensure technical sustainability, including maintenance of the specifications and software (versioning and bug fixing) and deployment of software modules.

e-SENS and also the CEF are key success factors which will have an impact for the (long-term) sustainability of e-CODEX. It is envisioned that CEF could support the central-maintenance of the e-CODEX components, which are not under the control of any other stakeholder group and provide common services to the EU Member States.

Architecture

e-CODEX has developed different BBs, which will be piloted in the different domains of e-Justice.

The following architectural BBs have been developed by e-CODEX:

e-Delivery Basic Transport Layer (Gateway) (Open source solution: OASIS ebMS340)

Generic Connector (Trust-token for signature validation, ASIC-S container, ETSI REM41

evidences)

Container for Documents and Signatures (Library to build an ASIC-S container / ETSI ASIC-S)

36

Small Claims Use Case: https://joinup.ec.europa.eu/catalogue/asset_release/e-codex-small-claim-xml-

schemas

European Payment Order: https://joinup.ec.europa.eu/catalogue/asset_release/e-codex-european-payment-order-xml-schemas 37

Two XML schemas, which are used in the use cases EPO and Small claims are available on JoinUp. 38

Each Member State will be hosting its own gateway and connector (the national connector is a part of the

connector responsible for the connection of the e-CODEX infrastructure to the national backend system). The gateway, connector and national connector of the e-Justice Portal will be hosted by DIGIT, but it is not a central component but only one gateway among other gateways. 39

Jira is a proprietary issue tracking product used for bug tracking, issue tracking and project management.

More information: http://en.wikipedia.org/wiki/JIRA 40

OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features Committee Specification 02,

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/cs02/ebms_core-3.0-spec-cs-02.html, 12 July 2007 41

ETSI T102-640-1, Version 2.1.1, Electronic Signatures and Infrastructures (ESI);Registered Electronic Mail

(REM)

https://joinup.ec.europa.eu/catalogue/asset_release/e-codex-small-claim-xml-schemas

https://joinup.ec.europa.eu/catalogue/asset_release/e-codex-small-claim-xml-schemas

https://joinup.ec.europa.eu/catalogue/asset_release/e-codex-european-payment-order-xml-schemas

https://joinup.ec.europa.eu/catalogue/asset_release/e-codex-european-payment-order-xml-schemas

http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/cs02/ebms_core-3.0-spec-cs-02.html

Pending EC approval


Signature creation (DSS tool)

Signature Validation (DSS tool)

XML Data Model (UN/CEFACT CCTS and partial re-Use of SEMIC.EU)

e-Delivery evidences (re-using some parts of evidence builder code from SPOCS – ETSI TS 102 640)

Figure 5 e-CODEX headlines for the GOA model

Governance

Operations

EC, MS (possibly Ministries of Justice) to play prominent role. Standardisation Organisations (e.g. OASIS) as part of governance to be decided in the future

e-CODEX takes into account different regulations, directives and decisions

Involvement of IT industry and end-users is important.

-

Architecture

Convergence: Roadmap toward a common e-Delivery protocol

Central repository and its maintenance by a central organisational unit

Technical components hosted and maintained on European level (JoinUp) and on national level

Pending EC approval


3. Integrated view of LSP Sustainability Plans In this chapter, the integrated view of the LSP sustainability plans is presented. The description present the sustainability plans based on the current findings and compare them. In other words, this deliverable will be the baseline for the e-SENS sustainability plan presenting the common denominations found within the previous LSPs. The presentation will follow the GOA models, i.e. first the integrated view on governance is described, then what can be deducted in relation to operations and then finally the common denominators in regards to architecture. The issues that require special attention are summed up as:

Re-use of BBs,

Uptake in market and

Willingness to continue support.

3.1. Governance Governance refers to an organisational structure and its management in order to ensure the sustainability of the technical solutions developed by the different LSPs. In this regard governance concerns the decision-making process, the involvement of different stakeholders and the responsibilities, which need to be carried out. The latter one will be further elaborated in the following sections. A governance structure should guarantee the deployment, running and the quality level/ maturity of the technical solutions and services offered.

The following table summarises the analysis of the governance approaches of the different LSPs:

PEPPOL SPOCS STORK epSOS e-CODEX

Stakeholders

Involved DGs (EU level)

DG DIGIT DG MARKT DG DIGIT DG SANCO DG Justice, DG DIGIT, DG MARKT, DG CONNECT

Public sector (national level)

National, regional and local administrations

National and local administrations, competent authorities responsible for implementing the Service Directive, PSCs

National, regional and local administrations, STORK Member State Reference Group, STORK 2.0 “Member State Council”

National and regional Ministries of Health, e-Health Governance Initiative (eHGI), e-Health Network of national authorities (eHN)

National and regional Ministries of Justice

Pending EC approval



Stakeholders

Private sector IT -service providers, suppliers of goods and services to the public sector

Entrepreneurs, service providers, IT industry

Businesses and service providers, NGOs, STORK Industry Group

Consortium of Industries (service providers e.g. hospitals, health professional)

IT industry, legal professionals

Standardisation Organisations

CEN BII, OASIS ETSI

OASIS, ETSI

Others

Chambers of Commerce

IHE, Continua, HL7

CCBE, CNUE, EUROJUST

Pending EC approval


Legal Framework


Directive on public procurement42

A strategy for e-Procurement43

Directive on electronic invoicing in public

procurement44

Single Market Act II45

Service Directive46

Single Market Act II47

eIDAS-Regulation48

European Directive “on the application of patients’ rights in cross-border health-care”49

Multi Annual European e-Justice Action Plan 2009-201350 (will be updated);

Strategy toward a European e-Justice51

Current governance approach

OpenPEPPOL

ISA Programme

e-SENS

Starter Kit/ JoinUp

DG Markt and EUGO Platform

ISA Programme (STORK)

still in progress

still in progress

decision made by the epSOS

still in progress

e-CODEX Sustainability Plan

42

PROPOSAL FOR A DIRECTIVE OF THE EUROPEAN PALIAMENT AND OF THE COUNCIL on public procurement

(COM(2011) 896 Final, 20.12.2011) 43

“Strategy for e-Procurement” (COM(2012) 179 final, 20.4.2012) 44

Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on electronic invoicing in

public procurement (COM(2013) 449 final -2013/0213 (COD), 26.6.2013) 45

“Single Market Act II – Together for new growth” – Key Action 10 (COM(2012) 573 final, 3.10.2012) 46

Directive 2006/123/EC of 12 December 2006 on services in the internal market 47

„Single Market Act II –Together for new growth” – Key Action 8 (COM(2012) 573 final, 3.10.2012) 48

Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on electronic

identification and trust services for electronic transactions in the internal market (2012/0146 COD): This regulation will provide the legal basis for the mutual recognition of foreign e-ID credentials and for the provision of cross-border e-ID services based on STORK, and will define the basic steps for further adoption of the e-ID solution to access public services. 49

DIRECTIVE 2011/24/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 9 March 2011 on the

application of patients‘ rights in cross-border healthcare. 50

Multi-Annual European e-Justice Action Plan 2009-2013 (2009/C 75/01) 51

Communication from the Commission to the Council, the European Parliament and the European Economic

and Social Committee: Towards a European e-Justice Strategy (COM(2008)329 final)

Pending EC approval


e-SENS „Project Steering Board“

(D1.7, update D1.12)

Table 6: Governance incl. stakeholder per LSP

The information provided in the table above shows that in some LSPs the discussion on future governance and a possible governance structure is still on-going (epSOS, e-CODEX, and partly STORK/STORK 2.0), whilst others have already reached a conclusion since they have already ended (PEPPOL, SPOCS). A future governance structure, which will ensure the sustainability of the e-SENS BBs needs to take into account the governance approaches of the previous LSPs, the different stakeholders and also the legal framework. Each LSP involves different stakeholders, who currently play and will play an important role in guaranteeing the sustainability of the different LSP BBs and need to be involved when looking at a future governance structure of the e-SENS BB. Stakeholders are “people or organisations that are concerned about, affected by, have a vested interest in or are some way with the issues addressed”52 by the different LSPs.

Involvement of the EU and public administrations

The European Union (DGs, other initiatives) as well as the Member States respective public administrations play an important role during the lifetime of each project and are supposed to play a central role in a future governance structure regarding the decision-making process according to the findings of e-SENS D3.453. The involvement of the EU or the national administrations depends on the responsibilities and tasks they will have in a future governance structure. That means that e.g. the EU should not have a decision-making power when it comes to tasks, which are carried out on national level (e.g. the hosting of national connectors or adapters as part of the transport infrastructure). Furthermore, the level of involvement of the public administration may differ regarding the requirements of the different LSPs. OpenPEPPOL is a NPO formed by the public and private sector, in which the private sector plays an important role. A strong centralised governance structure lead by the public sector would be challenging54. SPOCS, epSOS, STORK and e-CODEX are intrinsically publicly driven LSPs. The data processed by STORK and epSOS for example is private and sensitive. Therefore a prominent role for the private sector is debatable. A future e-SENS governance structure, which will ensure the sustainability of the BBs needs to consider both domain/ sector-specific and public / private requirements. It needs to be stressed that a future set-up and implementation of a governance structure will have to take into account existing operational organisations like OpenPEPPOL.

52

http://www.e-CODEX.eu/stakeholders.html 53 D3.4 has already listed that there is a strong need for a governance structure for the building blocks.

Cooperation at cross-border level is needed and the EC plays a role here. Experts in e-SENS have indicated the public administration must play a central role in the future governance structure and the decision-making process. Regarding the European level the same experts considered that it should have a coordinating role, and be decisive in case the subsidiary principle permits this. Experts in e-SENS commonly agree that Member States should play a very central role in the future governance structure, being decisive in the decision-making process. The private sector and standardisation organisations should be given an advisory role. 54

e-SENS D3.4 „Preliminary proposal for a governance body“; Chapter 2.1.3.2

Pending EC approval


Involvement of standardisation organisations, private sector and end user

The involvement of standardisation organisations, the private sector (e.g. IT-Industry, service providers) and the end users in a future governance structure is crucial55. These stakeholders provide knowledge, expertise and experience, which will improve the technical solutions, procedures and the services provided. Furthermore the IT industry may play an important role regarding the maintenance of the BBs.

These stakeholder groups may not be directly involved in the decision-making process, but may influence it. Their feedback, requirements and needs may be considered by addressing and consulting them. A possible consultation mechanism needs to be further elaborated. The involvement could take place through informal ways (e.g. workshops) or the establishment of different committees, in which the private and public sector cooperate56.

As seen in the table above there are a variety of stakeholders due to the diversity in domains. Depending on the domain different ministries, e.g. the Ministries of Justice in the judicial domain and Ministries of Health in the health domain may need to be involved in the future decision-making process. Also the involvement of the EU varies from domain to domain. For the juridical area the DGs are important as the European e-Justice portal and partly the e-CODEX assets are run by the EC (DG Justice resp. DG DIGIT).

Furthermore there are different initiatives and committees set up in the e-Health domain, which need to be consulted. This could be seen as a challenge for the set-up of a future governance structure since the variety of stakeholders which need to be involved may cause a high level of complexity. Therefore future investigations and elaborations are needed in e-SENS in order to create an efficiently working governance structure with an effective stakeholder management structure.

A future governance structure also needs to take into account the legal framework of the LSPs respectively for each of the different domains. It is important to closely monitor, influence and map legislative needs for the sustainability of the technical solutions.

The investigation of the governance approaches of the different LSPs revealed a complex landscape, where different requirements and stakeholders need to be taken into account. It is important to further investigate possibilities, common approaches, advantages and disadvantages regarding governance aspects and also consider already existing best practice-examples in order to set-up a future governance structure, which will ensure the sustainability of the e-SENS BB.

Continued support

The key question here is how the willingness of industry, the European Institution or other administration has been to continue their support to (parts of) BBs after expiration of the project.

The SPOCS BBs are not yet plug and play and support services are being addressed as part of the sustainability plan. Also, due to legal restrictions, documents sent by e-Delivery may not be treated as legally valid administrative documents in some countries, because they do not fall under a particular national act. The SPOCS BBs are used nationally and operated through national

PSCs.

For STORK, the consortium of the project agreed with the Commission that the STORK BBs would be taken, maintained and updated by the ISA programme of the EC. This decision was made to bridge

55

e-SENS D3.4 “Preliminary proposal for a governance body”, Chapter 3 56

e-SENS D3.5 „Preliminary proposal for long-term sustainability within the CEF“, Chapter 3.2.1

Pending EC approval


the gap until the CEF is in place. The objective of the ISA programme is to assure the sustainability of STORK BBs for the short-medium term. The same approach has been taken for epSOS, where EXPAND bridges the eHealth domain to CEF.

Although e-CODEX is still running, some of the central components are hosted by DG DIGIT (ISA Programme) and the MS are running the national connectors.

For PEPPOL, the continued support is secured by establishing the OpenPEPPOL NPO. It is a legal organisation set up to ensure the sustainability of the PEPPOL results. Different Working Groups within the OpenPEPPOL organisation are responsible for particular areas of specifications and components and follow commonly agreed procedures for Change Management, Release Management and support. An agreement is made with DG DIGIT to jointly management changes and DIGIT is responsible for Release Management. So, here a well-established continued support is found.

To conclude, continued support varies from not supported at present (e.g. SPOCS), through to supported by a programme (i.e. limited funding period, which is the case for e.g. e-CODEX) all the way to fully supported by a NPO (OpenPEPPOL).

1.1. Operations Operation is about the day-to-day running of the Digital Services. A reliable service management is a second prerequisite and needs to guarantee that the day-to-day operation of the expected services can be offered to customers. According to the GOA matrix, there are three pillars to define the operations chapter:

The Operational Service Management,

The Acceptance of new parties into the system and

The Training and Knowledge transfer.

Operational Service Management

To analyse the first of these pillars, the Operational Service Management, , it is necessary to know the maturity or willingness to support these projects, who are the users of the results, and finally study which is the model decided for every LSP to manage the lifecycle.

Currently, the LSPs whose operational results are most mature are STORK and PEPPOL in the sense that their BBs are taken care of in an organisation. For the assurance of the sustainability of their results some type of legal organisation has been created. In case of STORK, it has been the ISA program under the DG DIGIT who has taken over the results and works for their continuity, either improving them or promoting their usage among the European countries. In case of PEPPOL, an international association NPO under Belgian law, OpenPEPPOL, has been established in order to boost the results of the PEPPOL LSP. However, for both organisations no information is available on the openness of this organization and its maintenance procedures. In D3.2 Assessment on the maturity of BBs, some recommendations are given for openness and lifecycle management.

Although not so much mature as STORK and PEPPOL, SPOCS have created a SPOCS interoperability group to agree on new pilots to be developed under some European initiatives as e-SENS and EUGO.

Finally, epSOS and e-CODEX are still in progress, therefore the future governance model for their sustainability is still being discussed. However, for epSOS the EXPAND project has been set up although this does not address the legal sustainability.

The maturity of the BBs developed in the projects is an important factor for the take up of the results around Europe, but it is not the only one. Although all the LSPs were launched to produce results that allow European countries to interoperate and facilitate the deployment of cross-border digital

Pending EC approval


services, a key for their success is to legislate in the same direction. For example, epSOS supports the requirements of the European Directive 2011/24/EU on the application of patients’ rights in cross-border healthcare, while the results of STORK and PEPPOL are depending on the not yet approved Directives eIDAS and of e-Invoicing, respectively. These legislative acts can facilitate the take up of the solutions developed in the mentioned LSPs, otherwise Members States would not feel the obligation to adopt them. This is however not always the case. SPOCS is based on the Services Directive 2006/123/EC, and the take up and actual implementation of the directive is very low. Therefore a legal requirement does not necessarily speed things up. Another example is the signature directive 1999/93/EC that has not brought much change in the mutual recognition of qualified electronic signature. So, a legal framework can be one of many instruments that can contribute to sustainability. However, in practice, it is not always the case. According to the EC study on the needs and demands for cross-border services it is the business case that matters57.

Another element to define the Operational Service Management approach is the analysis of the user types based on their need for the results. At the moment, all the LSPs are quite focused on the public sector. Some of them also considered the private sector as potential users of the solutions, e.g. OpenPEPPOL established Coordinating Communities composed of both private and public sector and has included a service provider representative in the Managing Committee of the Association. In the case of SPOCS, the private stakeholders have had a consultative role during the whole project. The other three LSPs, STORK, epSOS and e-CODEX have had less contact with the private sector. This is much related to the type of domain they address. STORK, epSOS and e-CODEX are addressed to the public sector, as at this stage, it is the organisation that is authorised to handle eID authentication, healthcare and justice. However, in case of OpenPEPPOL and SPOCS it is the industry that benefits the most of the result.

Finally, to qualify the operational service management it is necessary to plan the lifecycle management. In the cases of STORK and PEPPOL, the lifecycle management is well defined in a set of structures and processes for inception, development, revisions, updates, work in progress, incremental version releases and phase out. Hence, their results from an operational service management point of view are the most mature ones. However, for both, the lifecycle management is not handled in an open maintenance organization.58 In the case of PEPPOL, it has set up a framework built upon the ITIL framework59. Although e-CODEX has not finalised its results it has created a central repository to upload all the documentation and software and which in the future shall be maintained by an organisational unit. epSOS uses a similar approach to e-CODEX, using an open source version management tool. Finally, SPOCS is the less developed one in this way, and expects to define its lifecycle management processes within e-SENS.

Acceptance of new parties into the system

The second pillar of this chapter is the acceptance of new parties into the system. In this regard, it is necessary to know the market engagement strategy followed by each LSP. After analysing the market engagement strategy of each LSP it is observed that the core of it is building business cases to identify the stakeholders whom the LSP should address. However, there are two different

57

http://ec.europa.eu/digital-agenda/en/news/final-report-study-analysis-needs-cross-border-services-and-

assessment-organisational-legal 58

D3.2 Assessment on the maturity of building blocks 59

http://www.itil.org/

Pending EC approval


approaches regarding when to design the business cases: either at the beginning of the project or after the project has delivered its first results.

In the first group we can find STORK and SPOCS that have designed the business case at the beginning of the project, whereas in the second group we can find PEPPOL and epSOS who have delivered the business case after delivering the first results. The first group of LSPs conceived the business case as a tool to identify the stakeholders who they should address during the project. In case of STORK, this step was essential to establish a clear picture of the European eID platform and the different requirements and expectations that its stakeholders may have. The second group of LSPs conceived the business case during the project to assure the sustainability of its results.

In both cases the marketing plan involved key messages, factsheets and presentation, videos, cases studies, stakeholder feedback, and a website content to present a more user-friendly source of information about each LSP activities.

The future addition of new partners will be closely related to the work made by the marketing team in e-SENS, together with the decisions taken by the organisation in charge of the results of every LSP.

Training and knowledge transfer

Thirdly, training and knowledge transfer is related to the take-up of the solution, so this point has been analysed for each LSP. The main challenges identified for the LSPs for the take-up of the solutions are:

The necessity of a high level of maturity of the solutions,

The flexibility of the solutions to assure that they meet different requirements,

The readiness of the key stakeholders (normally the public sector) to kick-start the initiatives, and adapt their IT systems to the new solutions,

The adoption of legislative measure,

The need for a sound and stable governance structure for the sustainability of the resulted BBs,

A reliable service management and a solid technical support to the MS,

The involvement of the industry during all the project development phases,

A transparent and open mechanism to address new solutions, and finally,

The development of ways to recruit new members (public and private sector) as organising workshops.

Take up

The key question here is basically how the current take-up in the market has been for the various LSPs and their BB. Here, „market“ is understood as the industry putting themselves in the (co-)driver seat to ensure development and deployment of the BB.

In this view, OpenPEPPOL is the most mature. Since the project completion in 2012, PEPPOL components have been implemented in 12 European countries to date, with over 60 PEPPOL Access Points established and interest also increasing now from outside of the EU. PEPPOL Access Points implemented by August 2012 = 51; as of June 2013 = 60.

For SPOCS, eight of the nine pilots are live online in PSC environments in Austria, Germany, Greece, Italy, Lithuania, Poland, Portugal, and Slovenia. Several more countries, including Romania, are planning to integrate the SPOCS modules and some plan to connect different regional agencies.

Pending EC approval


e-CODEX pilots are being run by judicial institutions. Piloting started in July 2013 in four different MS, namely Austria, Estonia, Germany and Italy. Further countries will join until the end of the project. Until now no BBs have yet been taken-up by the market.

The epSOS pilot is running until June 2014. In the project, the epSOS Industry Team, of more than 40 companies (small, medium and large enterprises and multinationals) involved in the eHealth market have participated actively to the specification phases, to the definition of the implementation strategy and in the validation phase. A consortium composed of beneficiaries and vendors was created to implement a reference architecture for the epSOS pilot. When it was decided to implement the Open Source NCP, some vendor members of the Industry Team joined in the implementation team.

For STORK, the regulation on eIDAS will provide the legal basis for the mutual recognition of foreign eID credentials and for the legal provision of cross-border eID services which will be a strong incentive for the MS to adopt for example the STORK eID solution.

1.2. Architecture In the context of the LSPs and the interoperability in the European Union, the architecture should indicate the different options in terms of the collaboration between the MS and the EC. The term architecture expresses in different standards the different elements related to the organisation of an information technology system, its components, its relationships and the principles governing its design and evolution over time.

Developed BBs

The solution BBs that have been developed in each LSP are:

PEPPOL SPOCS STORK epSOS e-CODEX Solution BBs

e-Delivery

e-Signatures

Virtual Company Dossier

e-Catalogues

e-Ordering and e-Invoicing

e-Delivery

e-Documents

e-Safe

e-Services & Syndication

SPOCS TLS

e-ID (these include STORK PEPS and STORK V-IDP)

Patient Summary

e-Prescription and e-Dispensation

Consent Service

Terminology Services Access Manager

Identification Service

Standards and Specifications and Common Code

• e-Delivery

• Generic Gateway and Connector

• e-Signature

• e-Semantics

Table 7: High-level BBs developed per LSP

Centralised and decentralised services The architectures of PEPPOL, STORK, epSOS and SPOCS are decentralised based on international standards for national interfaces or so called national connectors. The national connectors/adapters are implemented by the Member States and it is also their responsibility to maintain the software.

Pending EC approval


There are certain central components in PEPPOL and SPOCS, which are neither hubs nor portals, but only provide auxiliary services such as routing, discovery and semantic mapping. Within the e-CODEX and epSOS infrastructures there are some components that need to be hosted and maintained at European or central levels, whereas other components will be hosted in the Member States.

The software of the LSP BBs is all based on open source. The BBs of STORK, epSOS, PEPPOL and SPOCS are available at the JoinUp portal. e-CODEX published so far two components on JoinUp60. Common technology issues are at the very centre of the e-SENS project. However, the sustainability solutions designed by each LSP have very little in common.

Although this is clearly part of the mission of the e-SENS Project and it is foreseen as a “requirement” in many studies and documents, the role of a central architectural governance unit in defining principles and vision to be applied to the solution developed and to various kinds of BBs seems to be taken into account only in a minority of cases.

When comparing the conceptual design of the five LSPs, the overarching architectural solution seems to be mostly project oriented.

The predominant use of Open Source components guarantees the availability and a low entry level for most of the developed solution/BBs. It also provides good foundations for the ICT industry to build products and services upon.

The large use of standards based specifications allows their maintenance by the corresponding technical committee, thus leaving both the promoters and the adopters free to decide whether or not to participate in this activity. Both models, centralised and decentralised, are concurrently viable and the development of coherent solutions/BBs, based on common specifications, can be guaranteed even in the presence of a centralised governance body, leaving ample “space” for private stakeholders to raise their technical needs.

The use of state-of-the-art technology to create interoperable solutions and remove barriers in implementation of cross border services has been a key element in all of the LSP’s. This has created a number of efficient domain optimised set of BBs to support the use cases at hand.

Re-use

The key question here is whether any BB has been re-used from one LSP to the other. In SPOCS the eID solution created by the STORK project has been re-used. Apart from this, no other LSP has re-used the eID solution created by the STORK (or any other LSP for that matter).

The e-Signature validation solution from PEPPOL has been used in SPOCS. In STORK 2.0, a PEPPOL-like e-Signature validation has been developed based on the PEPPOL e-Signature61

However, when it comes to the e-Delivery solution a convergence has been initiated. e-CODEX together with PEPPOL and SPOCS have made an effort to define a commonly used e-Delivery architecture and run on a common infrastructure. This approach continues in e-SENS. The converged e-Delivery solution is pilot tested in e-CODEX, however the PEPPOL elements are commonly adopted and include the multiple gateway topology which is essential for the e-Procurement domain.

60

Two XML schemas, which are used in the use cases EPO and Small claims are available on JoinUp. 61

The user is re-directed via STORK PEPS/V-IDP to the signature service in his home country, but the signed

document is validated in the country of the service based on the PEPPOL e-Signature validation.

Pending EC approval


When it comes to the BB e-Documents, this intrinsically requires that the content of the documents sent use some kind of similar content. This has been the case where the PEPPOL VCD has been generalised into an OCD to package company information for transmission to PSCs in other countries, i.e. in SPOCS. e-Documents are usually dedicated to specific functions, like medical prescriptions, and there might be less need to re-use this in other domains. Nevertheless, the shared methodology and mapping to common vocabularies62 can increase the value and improve semantic interoperability. Further to this, the OCD, consists in a container format for documents that is agnostic to the payload; meaning that this can be re-used for different content in terms of format and metadata.

So, in conclusion one can say „yes“ attempts have been made to reuse BB from one LSP to another, but only rarely has this really happened. STORK eID in SPOCS, PEPPOL e-Signature in SPOCS and STORK 2.0 and PEPPOL VCD in SPOCS are the most prominent examples of re-use in the LSPs. Some of the big challenges in e-SENS lie in the fact that multiple/multi-formed LSP-solutions exist for the BBs and that only very limited attempts have been made to converge these in the individual LSPs. The LSPs have been project-oriented and for all LSPs it was necessary to some extend to build all four HBBs. No LSP could run without just one of the HBBs. As mentioned above, the eDocument HBB has sector-specific features and convergence could take place in for example mapping common vocabularies. For STORK, it is obvious that the eID BB is the most prominent, and for PEPPOL for instance, its success lies in exactly the fact that the e-Delivery BB can be used to transport various kinds of documents, e.g. eInvoice, eOrdering, VCD. The next section will further elaborate upon the findings by developing recommendations.

62

https://joinup.ec.europa.eu/sites/default/files/egovernment-core-vocabularies.pdf

https://joinup.ec.europa.eu/sites/default/files/egovernment-core-vocabularies.pdf

Pending EC approval


4. Conclusions and Recommendation The purpose of this deliverable is to get an overview of the different LSP sustainability plans, find their commonalities and present this. This overview will be used as a foundation to elaborate on the coming e-SENS sustainability plan.

4.1. Conclusions Governance

The only LSP that has set up a working governance model is PEPPOL with the private NPO, OpenPEPPOL, with the participation of MS and EC (e-SENS D3.4, page 24). The governance of STORK results have been taken up by a committee under the ISA programme where MS take part in the decision-making process. SPOCS has established an Interoperability Group to ensure the continued operation of their pilots. When it comes to governance, the judicial (e-CODEX) and health (epSOS) domains find it vital that the MS have a decisive role in cooperation with the EC. For both LSPs, until now no governance structure is set up after project end. For epSOS, the decision-making process is within the project PSB, where Ministries of Health are represented. The same is the situation for e-CODEX, where the Ministries of Justice are represented. Furthermore DG Justice needs to be involved as they are running the European e-Justice Portal.

When looking at the users of the systems, the LSPs have mostly focused on the public sector. However, OpenPEPPOL has established CCs that are made up of both private and public sector. This also goes for SPOCS where the private stakeholders have had a consultative role during the whole project.

In contrast to this, STORK, epSOS and e-CODEX are mainly addressed to the public sector, as it has the authority when it comes to eID authentication, healthcare and justice.

Operation

When it comes to operation, the variety in sustaining the solutions is rather important. OpenPEPPOL is advanced and running in a number of countries with thousands of transactions. Three LSPs have a solution running in cooperation with DG DIGIT under the ISA Programme: OpenPEPPOL, STORK and e-CODEX. DG DIGIT is managing operation services and/or hosting parts of the infrastructures. The SPOCS Interoperability Group manages involvement of new pilots. For epSOS and e-CODEX, operation services are managed in the projects. For the eHealth domain, assets are sought and secured by the EXPAND project. When it comes to lifecycle management, PEPPOL has set up a framework built on ITIL. STORK has a strong support from ISA including a MS steering committee to manage changes. e-CODEX and epSOS - as they are still running – have secured their assets in central repositories, e.g. JoinUp.

PEPPOL is the only LSP where one can talk about market take-up: The PEPPOL components have been implemented in 12 European countries, with over 60 PEPPOL Access Points established and with still increasing volumes of transactions. The rest of the LSPs have not yet been taken-up by the market. SPOCS, however, is still live in seven of the original piloting countries and e-CODEX, epSOS and STORK 2.0 pilots are run by government institutions as part of the running projects.

Architecture

Pending EC approval


The architectures of PEPPOL, STORK, epSOS and SPOCS are decentralised based on international standards for national interfaces. Central components exist in PEPPOL and SPOCS, that provide auxiliary services, e.g. semantic mapping. For e-CODEX and epSOS infrastructure, some components need to be maintained on a central level. Software from all LSPs are open source and available on JoinUp (For e-CODEX, however, only two schemas are available on JoinUp at present, see e-CODEX overview p. Fehler! Textmarke nicht definiert.).

The architectural solutions in the LSPs are mostly project oriented. Attempts have been made to reuse BBs from one LSP to another, however this has happened in few cases. SPOCS has used the eID BB from STORK, and both the VCD and the e-Signature validation from PEPPOL, STORK 2.0 has partly re-used the PEPPOL e-Signature validation. Apart from this, no significant re-use has taken place.

The predominant use of Open Source components guarantees the availability and a low entry level for most of the developed solution/BBs and provides good foundations for the ICT industry to build products and services upon.

The conceptual design of an overarching architectural solution is still mostly project oriented. Common technology issues are at the very centre of the e-SENS project and the sustainability solutions designed by each LSP have very little in common.

When it comes to re-use of BBs one can conclude that attempts have been done to reuse BBs from one LSP to another, but only rarely has this really happened, as mentioned above.

4.2. Recommendations From a strategic perspective the following recommendations can be considered:

A strategic vision from a user perspective (business and citizens) and the underlying strategy to support this, needs to be considered in e-SENS. There is a risk that the sole focus will be on the technical objective to re-use the BBs.

The LSPs have predominantly been working in silos. This calls for a strong governance system to make choices where the individual LSPs cannot make final conclusions. Otherwise, there is a risk of divergent solutions.

There is a need to look at the different LSP results from an end-user point of view, i.e. for instance businesses, courts and patients. This approach should also be considered in the definition of use cases from which the e-SENS vision can be drawn. This exercise can be done at sectorial level, or even at transaction level for example and should be addressed in the development of Business Cases, as part of the e-SENS WP3 work.

Pending EC approval


4.2.1. Governance From a governance perspective, it is important to recognise that a one-size fits all organisation might not be a viable solution considering the variety of stakeholders involved as well as targets and user needs. A multi-level organisation that can take on board private/public, national/cross-border, and domain-specific/generic interests seems to be an attractive solution. However, the CEF states that generic should have priority over sector specific solutions.

As has already been listed in D3.4 “Preliminary proposal for a governance body”, cooperation at cross-border level is needed and that the EC should play a coordinating – and to some extent a decisive role with the public administration playing a central role in the future governance structure and the decision-making process.

Based on a range of conclusions from the EC sustainability study, any cross-LSP governance structure, technical architecture, centralised/de-centralised services or PSCs need to be flexible and scalable in order to adapt for the different levels of maturity in the current LSPs. Flexibility is furthermore needed for new/additional Member State involvement, for any change in the mix of public vs. private sector stakeholder involvement (including methods of funding), for further enhancements and expansion of the BBs and related services, and for increases in activity as adoption levels increase.

4.2.2. Operation With respect to operational issues these recommendations can be considered:

There is a risk that each LSP starts operating its own sustainability organisation that maintains the BBs produced in that specific LSP. As it is clear that some LSPs have developed similar/identical BBs (like eID or e-Delivery), the risk is that similar BBs will be maintained by different sustainability organisations. Another issue is the overlap of BBs. This risk can be mitigated either (1) by allowing e-SENS to develop a combined BB that is maintained in one of the sustainability organisations, or (2) setting up a single sustainability organisation that deals with the combining of similar BBs. In the first case, multiple sustainability organisations can exist in parallel, but they all maintain BBs for different functionalities. An important requirement is that there is a strong interaction and guidance between these sustainability organisations regarding which BBs are maintained and by whom. In general, the convergence of the BBs would require a strong (political) governance from MS and EC. It is a challenging task to leave this to e-SENS alone.

Under the assumption that there will initially be a situation with multiple sustainability organisations originating from the various LSPs, it is most important to have a single point of access for European governments into these organisations and the BBs they maintain. A central programme/unit/DG at the EC, could be a good candidate for such a role, (like the JoinUp repository used as a central repository for specifications and software). The function of such a single point of access is to provide a complete overview of the BBs maintained/prescribed and guide governments towards the proper sustainability organisation for the correct specifications and documentation.

As mentioned, the organisation of a mature life-cycle management process is currently lacking in the sustainability plans that are formed in most of the LSPs. It is important to have this in place and in that respect reuse can be made of existing models for how to organise life cycle management, e.g. based on OpenPEPPOL and ITIL.

Pending EC approval


4.2.3. Architecture With respect to technological issues, the following recommendations can be considered:

The technology is constantly evolving and bringing new opportunities to the market and it is imperative that the solutions from e-SENS and the sustainability efforts must be open to adopt new technology and prioritise this in an on-going lifecycle management strategy. From a technical perspective the use of generic models and open architectures with proven methodologies are an important part of facilitating such efforts. An example of this is the use of the EIF that structures requirements and the BBs systematically in an open and consistent manner. This opens the way for adoption of new technologies to solve specific functions in a framework while still retaining the overall model and structures – making reuse of other BBs easier and protecting investments.

A number of BBs are based on international standards and specifications, for example the e-Signature BBs are based on the EU Standards Framework for e-Signature developed by ETSI. From this point of view, it is important to limit the role of the sustainability organisation(s) to the provisioning and maintenance of the high-level BBs, like e-ID and e-Signature, and specify how international standards are being used in these BBs. The actual maintenance of the international standards will then be done by international/European standardisation organisations like ISO, CEN, CENELEC, ETSI, IHE, HL7, IETF, W3C, OASIS, etc.

Through the use of structured metadata and common methodology for signatures, encryption etc., it is possible to efficiently send and route e-Documents to the right recipient retaining confidentially and integrity. Structured XML documents can provide the possibility for full or partial automation of content with increased productivity and significant savings in many use cases. Such examples of e-Documents are usually dedicated to specific functions like medical prescriptions or e-Invoicing and will not be generic and reusable in other domains. But the shared methodology and mapping to common vocabularies63 can increase the value and improve semantic interoperability

4.2.4. Re-use, take-up and continued support From a market take-up perspective these recommendations can be considered:

Considering that stakeholder involvement has been an important common achievement across all LSPs, in-depth stakeholder mapping carried out in conjunction with e-SENS WP2 is necessary to leverage on the network and better reflect these relationships and informational flows in the organisational design for a future governance body. The network of LSPs relations with all interested bodies can be converged into one single structured network that can become an important synergy. This is particularly true with regards to the IT industry and standardisation bodies.

For the adoption of specific solutions, it is important to assess the costs for end-users as part of the business case, as well as the maintenance costs of centralised vs. decentralised components for public sector organisations. The assessment needs to be realistic based on market rates and not on theoretical assumptions.

To ensure compliance of ICT solutions (based on e-SENS specifications) with EU requirements, a reliable test and conformance facility should be provided.

64

Joint e-SENS workshop with Architectural Board, Domain Board and WP3 leaders for alignment on

sustainability and governance. Turin, 17 September 2013.

Pending EC approval


EU policies and legislative measures have to support the adoption of BBs and, in general, the results of the e-SENS project. Member States legislation should be harmonised, since this remains the most significant issue across all LSPs

Key factors critical for market take up: based on feedback gathered during an e-SENS workshop64 - are the common elements of a well implemented life-cycle management process: stable and up to date versions of the specifications, clear and easy to access documentation and implementation guidelines, reliable test and conformance tools. These are all elements which if properly handled will sign the successful adoption of the early movers, and, vice versa, will cause significant challenges to adopters in the initial pilot phases and impact decisions for further investment.

From a re-usability perspective these recommendations can be considered:

The re-use of BBs and different LSP results could be envisioned also at sectorial level, or even at transaction level65, and should be addressed in the development of the e-SENS business case. For example, the Swedish construction industry will start using the PEPPOL e-Delivery component to exchange the industry specific messages within their community66.

Where possible, for future e-SENS success, it will be important to ensure that cross-border services/solutions are suitable for re-use at national and regional level.

In respect to market take-up most solutions need further additional work in order to align with national/regional solutions, mostly because of the extreme variety of the latter and of the difficulty of imposing “standards” on Member States.

Some of the solutions/BBs are just “not made-for-the-market”, meaning they will continue to be publicly owned and managed because this is in their nature (or are unanimously considered to be so at the present time). e-SENS needs to investigate these elements and find a sustainable solution for this problem. Either continued public financing is a solution or further technological development so that solutions will eventually be accepted by the market, so that continued financing can be avoided.

It is also worth mentioning, that no BB originating from another LSP can „just like that“, be plugged into a different LSP and be running without any changes to the LSP or the BB. It will need at least some re-engineering. Although e-SENS was created to consolidate, improve and extend this is nevertheless what e-SENS needs to look at. In this process, e-SENS might end in a dilemma between the take-up of the market (market maturity) and the convergence of the BBs. What is the most important? Maturity that will ensure the market that a BB is ready for take-up, or convergence that might require re-engineering and hence prolong the time for market take-up – or even lead to a diverging market if some market mature BBs have already been taken up by a major part of the market.

64

Joint e-SENS workshop with Architectural Board, Domain Board and WP3 leaders for alignment on

sustainability and governance. Turin, 17 September 2013. 65

Example: Real Estate cross-border transaction

Scenarios: Buying or building a property abroad.

Actors: notaries, real estate agents, architects, construction companies, legal firms, buyers, sellers, banks and insurance companies.

Possible Solutions/BBs to be used: Business Registry; Land registry; e-Delivery; e-ID; e-Documents; e-Signatures. 66

http://www.peppol.eu/news/swedish-construction-organisation-beast-joins-peppol

Pending EC approval


5. References Final Report - Study on “The feasibility and scenarios for the long-term sustainability of the Large Scale Pilots, including 'ex-ante' evaluation”. (SMART 2012/0059)

Final Report - Study on “Analysis of the Needs for Cross-Border Services and Assessment of the Organisational, Legal, Technical and Semantic Barriers”. (SMART 2011/0074)

‘A guide to setting up the management of open standards: BOMOS2i: The practical approach’ - Dutch Standardisation Forum. October 2012

epSOS Deliverable 5.2.1. Initial Scope - Version 1.0 - 28/01/2009

Deliverable 3.B.1 epSOS 2 Implementation Strategy - Version 0.14 - 20/05/2011

epSOS Sustainability and Implementation Strategy - 20/01/2013

epSOS Deliverable 3.3.3 epSOS Interoperability Framework - Version 2.3 - 15/04/2010

Deliverable 2.1.2 ‘Legal and Regulatory Constraints on epSOS Design ‐ Participating Member States’ - Version Final – 31/01/2010

Deliverable 3.3.3 epSOS Interoperability Framework - Version 2.3 -15/04/2010

Deliverable 7.18 SPOCS Sustainability Plan – Sustainability of SPOCS concepts, building blocks and interoperability piloting - Version Final-REV1 – 22/01/2013

Deliverable 7.12 & Deliverable 7.19 SPOCS ‘Final Report’ - Version Final REV1 – 22/01/2013

Deliverable 1.7 e-CODEX Sustainability Plan - Version 0.8 – 03-07-2012

e-CODEX Deliverable 5.2 Reusable Assets - Appendix I “Scenario for the Convergence of LSP e-Delivery solutions” - Version 0.5 – 29/08/2011

e-CODEX Deliverable 5.3 Concept of Implementation - Version 1.0 - 05/04/2012

STORK D7.8.2 Sustainability Action Plan - Version Final - 11/11/2011

STORK Sustainability Study Final report - Version Final - 15/09/2011

Deliverable 6.17 PEPPOL Final Report - Version Final – November 2012

Deliverable 7.6 PEPPOL Long Term Sustainability - Version 1.0 Final – 27/08/2012

“PEPPOL Business Case for Sustainability” Study - Version 1.0 Final – 03/10/2011

PEPPOL Starter Kit - Version 1 - September 2011

Pending EC approval - e-SENS | Moving services forward! · SWOT...

Documents

Transcript of Pending EC approval - e-SENS | Moving services forward! · SWOT...