Submitted to the EC on 11/06/2015
Project acronym: e-SENS
ov
al
COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME
ICT Policy Support Programme (ICT PSP)
pr
Project full title: Electronic Simple European Networked Services
ICT PSP call identifier: CIP-ICT-PSP-2012-6
ap
ICT PSP main theme identifier: CIP-ICT-PSP-2012-6-4.1 Basic Cross Sector Services
EC
Grant agreement n°: 325211
g
D5.4-2: Second-wave Update of Plans and Status of Domain and National
Pilots in eHealth
in
Deliverable Id :
Pe
nd
Deliverable Name :
D5.4-2
Second-wave Update of Plans and Status of Domain
and National Pilots in eHealth
Version :
V1.0
Status :
final
Dissemination Level :
Public
Due date of deliverable :
M22
Actual submission date :
11/06/2015
Work Package :
Organisation name of lead partner for this deliverable :
Author(s):
WP5
UPRC
Dimitrios G. Katehakis, Angelina Kouroubali, Ioannis
Petrakis, Fokion Logothetidis (FORTH, GR), George
Pangalos, Zoi Kolitsi (AUTH, GR), Lefteris Leontaridis,
Andriana Prentza (UPRC, GR), Marcello Melgara,
Roberto Zuffada (LIPSA, IT), Soeren Bittins, Olaf
(FOKUS, DE), John Stevens (CZ.NL, NL), Francois
Wisniewki (TUDOR, LU), René Hietkamp, Jeroen
Scheeres (VECOZO, NL), Massimiliano Masi (FMoH,
AT), Merle Laager (Medisoft, EE), Iciar Abad (MoH,
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 1
ES), Licinio Mano (SPMS, PT), Ruth Türk (East Tallinn
Central Hospital, EE), Merle Laager (Medisoft Ltd,
EE), Merike Künnapuu (West Tallinn Central Hospital,
EE), Margus Värton (EISA, EE), Andrzej Strug, Ewa
Korol (NFZ/Poland)
Partner(s) contributing :
Abstract:
Pe
nd
in
g
EC
ap
pr
ov
al
This report presents the domain pilot plans of the two domain use cases in the domain 5-2 eHealth, and the
national pilot plans for the MS/ACs participating in the domain.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 2
History
Date
Changes made
Modified by
0.1
01.09.2014
Creation of document
Andriana Prentza
0.3
31.10.2014
Description of domain use cases and
domain pilot planning
Dimitrios G. Katehakis,
John Stevens
0.5
23.11.2014
Input from all contributors integrated
Andriana Prentza
0.6
19.12.2014
Update of domain use case UC5.2.1
Dimitrios G. Katehakis
0.7
05.01.2014
Updated input after the F2F meeting in
Brussels integrated
Andriana Prentza
0.8
06.02.2015
Finalisation for 1 review round
0.82
27.02.2015
Integration of 1 review comments in
domain use case UC5.2.2
0.82
06.03.2015
Integration of 1 review comments in
domain use case UC5.2.1
0.84
12.03.2015
Integration of 1 review comments in
national pilot plans for use case UC5.2.2
0.88
09.04.2015
Integration of 1 review comments in
national pilot plans for use case UC5.2.1
Andriana Prentza
0.89
30.04.2015
Update of time plan for use case UC5.2.1
Dimitrios G. Katehakis
ov
al
Version
st
EC
st
ap
st
pr
st
in
g
st
review round
John Stevens
Dimitrios G. Katehakis
Andriana Prentza
0.9
05.05.2015
0.95
15.05.2015
Update of use case UC5.2.1
Dimitrios G. Katehakis
0.99
25.05.2015
Finalisation for submission to WP1
Andriana Prentza
1.0
11.06.2015
Final editorial amendments
WP1
Pe
nd
Finalisation for 2
nd
Andriana Prentza
Andriana Prentza
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.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 3
Table of contents
HISTORY....................................................................................................................................... 3
TABLE OF CONTENTS .................................................................................................................... 4
LIST OF FIGURES ......................................................................................................................... 11
LIST OF TABLES ........................................................................................................................... 12
LIST OF ABBREVIATIONS ............................................................................................................. 13
al
SCOPE AND OBJECTIVE OF THE DOCUMENT .................................................................................... 19
1.2.
STRUCTURE OF THE DOCUMENT ................................................................................................... 19
ov
1.1.
pr
DOMAIN PILOT PLAN OF USE CASE 5.2.1: EPRESCRIPTION/PATIENT SUMMARY ................... 21
USE CASE OVERVIEW .................................................................................................................. 21
2.2.
MOTIVATION AND GOALS............................................................................................................ 21
ap
2.1.
BACKGROUND AND RATIONALE............................................................................................. 21
2.2.2.
VALUE AND DOMAIN IMPORTANCE........................................................................................ 23
2.2.3.
SPECIFIC RELATIONSHIP WITH PRIOR LSPS OR OTHER DOMAIN INITIATIVES ................................... 24
g
2.3.
EC
2.2.1.
PROCESS DESCRIPTION: PATIENT SUMMARY ................................................................................... 29
in
2.
INTRODUCTION .................................................................................................................. 19
2.3.1.
ACTORS ............................................................................................................................ 29
2.3.2.
PRECONDITIONS ................................................................................................................ 29
2.3.3.
FLOW OF EVENTS ............................................................................................................... 30
2.3.4.
POST-CONDITIONS ............................................................................................................. 30
2.3.5.
ASSUMPTIONS ................................................................................................................... 30
2.3.6.
SPECIAL REQUIREMENTS ...................................................................................................... 30
2.4.
Pe
nd
1.
PROCESS DESCRIPTION: EPRESCRIPTION/ EDISPENSATION ................................................................ 31
2.4.1.
ACTORS ............................................................................................................................ 31
2.4.2.
PRECONDITIONS ................................................................................................................ 31
2.4.3.
FLOW OF EVENTS ............................................................................................................... 31
2.4.4.
POST-CONDITIONS ............................................................................................................. 32
2.4.5.
ASSUMPTIONS ................................................................................................................... 32
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 4
2.4.6.
2.5.
2.5.1.
OVERVIEW DIAGRAM OF ARCHITECTURE AND TOPOLOGY .......................................................... 33
2.5.2.
COMMON INTERACTION PATTERNS ....................................................................................... 34
2.5.3.
USE OF E-SENS BBS PER AREA ............................................................................................. 37
2.5.4.
USE OF ESTABLISHED INFRASTRUCTURE AT EU AND MS LEVEL ................................................... 58
2.6.
MS RELEVANCE ......................................................................................................................... 59
2.7.
PILOT PLANNING: PHASES, ACTIVITIES, MILESTONES, DEPENDENCIES ................................................. 61
DETAILED DESIGN OF PILOT .................................................................................................. 61
2.7.2.
TECHNICAL IMPLEMENTATION .............................................................................................. 67
2.7.3.
READINESS TESTING AND CONFORMANCE .............................................................................. 69
2.7.4.
LAUNCHING AND RUNNING ................................................................................................. 70
pr
ov
al
2.7.1.
ap
NATIONAL PILOT PLAN OF SPAIN FOR UC 5.2.1.................................................................... 71
3.1.
PILOT SCOPE ............................................................................................................................. 71
DOMAIN USE CASE TO BE PILOTED ........................................................................................ 71
3.1.2.
NATIONAL MOTIVATION AND GOALS .................................................................................... 71
3.1.3.
BUSINESS PROCESS OVERVIEW ............................................................................................. 72
3.1.4.
PILOT PARTICIPANTS AND STAKEHOLDERS............................................................................... 72
3.1.5.
PILOT TIMING.................................................................................................................... 72
in
g
EC
3.1.1.
3.2.
PILOT DESCRIPTION .................................................................................................................... 72
3.2.1.
PILOT SCENARIO................................................................................................................. 72
3.2.2.
USE OF E-SENS AND DOMAIN-SPECIFIC BUILDING BLOCKS ....................................................... 73
3.2.3.
USE OF NATIONAL INFRASTRUCTURE ..................................................................................... 73
3.3.
4.
ARCHITECTURE AND USE OF BUILDING BLOCKS ............................................................................... 33
Pe
nd
3.
SPECIAL REQUIREMENTS ...................................................................................................... 32
PILOT IMPLEMENTATION ............................................................................................................. 73
3.3.1.
IMPLEMENTATION PLANNING............................................................................................... 73
3.3.2.
PILOT RESOURCES .............................................................................................................. 73
3.3.3.
PILOT RISKS AND OVERALL FEASIBILITY ................................................................................... 73
NATIONAL PILOT PLAN OF GREECE FOR UC 5.2.1 ................................................................. 74
4.1.
PILOT SCOPE ............................................................................................................................. 74
4.1.1.
DOMAIN USE CASE TO BE PILOTED ........................................................................................ 74
4.1.2.
NATIONAL MOTIVATION AND GOALS .................................................................................... 74
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 5
4.1.3.
BUSINESS PROCESS OVERVIEW ............................................................................................. 75
4.1.4.
PILOT PARTICIPANTS AND STAKEHOLDERS............................................................................... 75
4.1.5.
PILOT TIMING.................................................................................................................... 75
4.2.
4.2.1.
PILOT SCENARIO................................................................................................................. 76
4.2.2.
USE OF E-SENS AND DOMAIN-SPECIFIC BUILDING BLOCKS ....................................................... 77
4.2.3.
USE OF NATIONAL INFRASTRUCTURE ..................................................................................... 77
4.3.
IMPLEMENTATION PLANNING............................................................................................... 77
4.3.2.
PILOT RESOURCES .............................................................................................................. 79
4.3.3.
PILOT RISKS AND OVERALL FEASIBILITY ................................................................................... 79
ov
al
4.3.1.
pr
NATIONAL PILOT PLAN OF ITALY FOR UC 5.2.1 .................................................................... 80
PILOT SCOPE ............................................................................................................................. 80
ap
5.1.
DOMAIN USE CASE TO BE PILOTED ........................................................................................ 80
5.1.2.
NATIONAL MOTIVATION AND GOALS .................................................................................... 80
5.1.3.
BUSINESS PROCESS OVERVIEW ............................................................................................. 81
5.1.4.
PILOT PARTICIPANTS AND STAKEHOLDERS............................................................................... 81
5.1.5.
PILOT TIMING.................................................................................................................... 82
in
g
EC
5.1.1.
5.2.
PILOT DESCRIPTION .................................................................................................................... 82
5.2.1.
PILOT SCENARIO................................................................................................................. 82
5.2.2.
USE OF E-SENS AND DOMAIN-SPECIFIC BUILDING BLOCKS ....................................................... 84
5.2.3.
USE OF NATIONAL INFRASTRUCTURE ..................................................................................... 85
5.3.
6.
PILOT IMPLEMENTATION ............................................................................................................. 77
Pe
nd
5.
PILOT DESCRIPTION .................................................................................................................... 76
PILOT IMPLEMENTATION ............................................................................................................. 85
5.3.1.
IMPLEMENTATION PLANNING............................................................................................... 85
5.3.2.
PILOT RESOURCES .............................................................................................................. 85
5.3.3.
PILOT RISKS AND OVERALL FEASIBILITY ................................................................................... 86
NATIONAL PILOT PLAN OF LUXEMBOURG FOR UC 5.2.1....................................................... 87
6.1.
PILOT SCOPE ............................................................................................................................. 87
6.1.1.
DOMAIN USE CASE TO BE PILOTED ........................................................................................ 87
6.1.2.
NATIONAL MOTIVATION AND GOALS .................................................................................... 87
6.1.3.
BUSINESS PROCESS OVERVIEW ............................................................................................. 88
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 6
6.1.4.
PILOT PARTICIPANTS AND STAKEHOLDERS............................................................................... 88
6.1.5.
PILOT TIMING.................................................................................................................... 88
6.2.
6.2.1.
PILOT SCENARIO................................................................................................................. 89
6.2.2.
USE OF E-SENS AND DOMAIN-SPECIFIC BUILDING BLOCKS ....................................................... 90
6.2.3.
USE OF NATIONAL INFRASTRUCTURE ..................................................................................... 90
6.3.
PILOT IMPLEMENTATION ............................................................................................................. 91
IMPLEMENTATION PLANNING............................................................................................... 91
6.3.2.
PILOT RESOURCES .............................................................................................................. 92
6.3.3.
PILOT RISKS AND OVERALL FEASIBILITY ................................................................................... 92
ov
al
6.3.1.
NATIONAL PILOT PLAN OF PORTUGAL FOR UC 5.2.1 ............................................................ 93
PILOT SCOPE ............................................................................................................................. 93
pr
7.1.
DOMAIN USE CASE TO BE PILOTED ........................................................................................ 93
7.1.2.
NATIONAL MOTIVATION AND GOALS .................................................................................... 93
7.1.3.
BUSINESS PROCESS OVERVIEW ............................................................................................. 94
7.1.4.
PILOT PARTICIPANTS AND STAKEHOLDERS............................................................................... 94
7.1.5.
PILOT TIMING.................................................................................................................... 95
EC
g
PILOT DESCRIPTION .................................................................................................................... 95
in
7.2.
ap
7.1.1.
7.2.1.
PILOT SCENARIO................................................................................................................. 95
7.2.2.
USE OF E-SENS AND DOMAIN-SPECIFIC BUILDING BLOCKS ....................................................... 97
7.2.3.
USE OF NATIONAL INFRASTRUCTURE ..................................................................................... 97
7.3.
Pe
nd
7.
PILOT DESCRIPTION .................................................................................................................... 89
PILOT IMPLEMENTATION ............................................................................................................. 97
7.3.1.
IMPLEMENTATION PLANNING............................................................................................... 97
7.3.2.
PILOT RESOURCES .............................................................................................................. 98
7.3.3.
PILOT RISKS AND OVERALL FEASIBILITY ................................................................................... 98
ANNEXES ..................................................................................................................................100
ANNEX I: PILOT PLAN ........................................................................................................................... 101
ANNEX II: REQUIREMENTS AND RECOMMENDATIONS – CHECKLIST .............................................................. 104
ANNEX III: SEQUENTIAL IMPLEMENTATION GUIDELINES ............................................................................. 113
ANNEX IV: EP/PS PN PILOT READINESS, REQUIREMENTS, AND RECOMMENDATIONS SHEET ........................... 118
8.
DOMAIN PILOT PLAN OF USE CASE 5.2.2: ECONFIRMATION ................................................122
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 7
8.1.
USE CASE OVERVIEW................................................................................................................ 122
8.2.
MOTIVATION AND GOALS.......................................................................................................... 123
8.2.1.
BACKGROUND AND RATIONALE........................................................................................... 123
8.2.2.
VALUE AND DOMAIN IMPORTANCE ..................................................................................... 123
8.2.3.
SPECIFIC RELATIONSHIP WITH PRIOR LSPS OR OTHER DOMAIN INITIATIVES ................................. 123
8.3.
ACTORS .......................................................................................................................... 124
8.3.2.
PRECONDITIONS .............................................................................................................. 125
8.3.3.
FLOW OF EVENTS ............................................................................................................. 125
8.3.4.
POST-CONDITIONS ........................................................................................................... 126
8.3.5.
ASSUMPTIONS ................................................................................................................. 126
8.3.6.
SPECIAL REQUIREMENTS .................................................................................................... 126
pr
ov
al
8.3.1.
ARCHITECTURE AND USE OF BUILDING BLOCKS.............................................................................. 127
ap
8.4.
9.
PROCESS DESCRIPTION.............................................................................................................. 124
OVERVIEW OF THE SOLUTION ............................................................................................. 127
8.4.2.
APPLICATION COMPONENTS AND THEIR FUNCTIONS ............................................................... 128
8.4.3.
ECONFIRMATION DOCUMENT EXCHANGE ............................................................................. 132
8.4.4.
USE OF E-SENS BBS PER AREA ........................................................................................... 135
8.4.5.
USE OF ESTABLISHED INFRASTRUCTURE AT EU AND MS LEVEL ................................................. 139
in
g
EC
8.4.1.
MS RELEVANCE ....................................................................................................................... 140
8.6.
PILOT PLANNING: PHASES, ACTIVITIES, MILESTONES, DEPENDENCIES ............................................... 140
Pe
nd
8.5.
8.6.1.
DETAILED DESIGN OF PILOT ................................................................................................ 140
8.6.2.
TECHNICAL IMPLEMENTATION ............................................................................................ 140
8.6.3.
READINESS TESTING AND CONFORMANCE ............................................................................ 141
8.6.4.
LAUNCHING AND RUNNING ............................................................................................... 141
NATIONAL PILOT PLAN OF ESTONIA FOR UC 5.2.2 ..............................................................142
9.1.
PILOT SCOPE ........................................................................................................................... 142
9.1.1.
DOMAIN USE CASE TO BE PILOTED ....................................................................................... 142
9.1.2.
BUSINESS PROCESS OVERVIEW ............................................................................................ 142
9.1.3.
ESTONIAN PILOT PARTICIPANTS AND STAKEHOLDERS .............................................................. 143
9.1.4.
PILOT TIMING.................................................................................................................. 143
9.2.
PILOT DESCRIPTION .................................................................................................................. 144
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 8
9.2.1.
PILOT SCENARIO............................................................................................................... 144
9.2.2.
USE OF E-SENS AND DOMAIN-SPECIFIC BUILDING BLOCKS ..................................................... 146
9.2.3.
USE OF NATIONAL INFRASTRUCTURE ................................................................................... 147
9.3.
9.3.1.
IMPLEMENTATION PLANNING............................................................................................. 148
9.3.2.
PILOT RESOURCES ............................................................................................................ 149
9.3.3.
PILOT RISKS AND OVERALL FEASIBILITY ................................................................................. 149
NATIONAL PILOT PLAN OF NETHERLANDS FOR UC 5.2.2 ..................................................151
DOMAIN USE CASE TO BE PILOTED ...................................................................................... 151
10.1.2.
NATIONAL MOTIVATION AND GOALS .................................................................................. 151
10.1.3.
BUSINESS PROCESS OVERVIEW ........................................................................................... 151
10.1.4.
DUTCH PILOT PARTICIPANTS AND STAKEHOLDERS................................................................... 152
10.1.5.
PILOT TIMING.................................................................................................................. 152
ap
pr
ov
10.1.1.
PILOT DESCRIPTION .............................................................................................................. 153
EC
10.2.
PILOT SCENARIO............................................................................................................... 153
10.2.2.
USE OF E-SENS AND DOMAIN-SPECIFIC BUILDING BLOCKS ..................................................... 156
10.2.3.
USE OF NATIONAL INFRASTRUCTURE ................................................................................... 157
in
g
10.2.1.
10.3.
11.
PILOT SCOPE ....................................................................................................................... 151
al
10.1.
PILOT IMPLEMENTATION ....................................................................................................... 158
Pe
nd
10.
PILOT IMPLEMENTATION ........................................................................................................... 148
10.3.1.
IMPLEMENTATION PLANNING............................................................................................. 158
10.3.2.
PILOT RESOURCES ............................................................................................................ 159
10.3.3.
PILOT RISKS AND OVERALL FEASIBILITY ................................................................................. 159
NATIONAL PILOT PLAN OF POLAND FOR UC 5.2.2 ............................................................161
11.1.
PILOT SCOPE ....................................................................................................................... 161
11.1.1.
DOMAIN USE CASE TO BE PILOTED ...................................................................................... 161
11.1.2.
NATIONAL MOTIVATION AND GOALS .................................................................................. 161
11.1.3.
BUSINESS PROCESS OVERVIEW ........................................................................................... 162
11.1.4.
PILOT PARTICIPANTS AND STAKEHOLDERS............................................................................. 162
11.1.5.
PILOT TIMING.................................................................................................................. 163
11.2.
11.2.1.
PILOT DESCRIPTION .............................................................................................................. 163
PILOT SCENARIO............................................................................................................... 163
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 9
11.2.2.
USE OF E-SENS AND DOMAIN-SPECIFIC BUILDING BLOCK ...................................................... 165
11.2.3.
USE OF NATIONAL INFRASTRUCTURE ................................................................................... 166
11.3.
11.3.1.
IMPLEMENTATION PLANNING............................................................................................. 166
11.3.2.
PILOT RESOURCES ............................................................................................................ 166
1.2.1
PILOT RISKS AND OVERALL FEASIBILITY ................................................................................. 167
REFERENCES ......................................................................................................................168
Pe
nd
in
g
EC
ap
pr
ov
al
I.
PILOT IMPLEMENTATION ....................................................................................................... 166
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 10
List of Figures
Pe
nd
in
g
EC
ap
pr
ov
al
Figure 1: Fundamental epSOS Architecture .................................................................................................... 24
Figure 2: epSOS Architecture Stack ................................................................................................................ 25
Figure 3: epSOS NCP-to-NCP Interaction Patterns .......................................................................................... 26
Figure 4: Circles of Trust (from STORK) ........................................................................................................... 27
Figure 5: Global eP/ PS Use Case Architecture................................................................................................ 33
Figure 6: Request of Data Interaction Pattern ................................................................................................ 34
Figure 7: "Request Overview and Pick Details" Interaction Pattern ................................................................ 35
Figure 8: “Provisioning of Data” Interaction Pattern ...................................................................................... 35
Figure 9: “Application Architecture” Interaction Pattern for Medical Data Exchange ..................................... 36
Figure 10: “Application Architecture” Interaction Pattern for ePrescription .................................................. 36
Figure 11: "Patient Identification and Authentication" interaction pattern.................................................... 41
Figure 12: Generic e-SENS eID Flow of Events ................................................................................................ 41
Figure 13: epSOS Assignment of Concerns in eID and AuthZ .......................................................................... 43
Figure 14: Patient identification service interaction ....................................................................................... 44
Figure 15: Encapsulation and Abstraction of national eID .............................................................................. 47
Figure 16: Retrieval & Mapping from eID to cross-sector Asserting ................................................................ 47
Figure 17: Capabilities of FutureID signature service ...................................................................................... 50
Figure 18: Capabilities of FutureID authentication service ............................................................................. 51
Figure 19: FutureID component deployment within a Trusted Zone of Country-B .......................................... 52
Figure 20: FutureID component deployment with public access in Country-A ................................................ 52
Figure 21: Traditional XCPD using Identity Traits ............................................................................................ 55
Figure 22: eID and XCPD combined workflow with no Re-Sequencing ........................................................... 56
Figure 23: eID-triggered Re-Sequencing without XPCD ................................................................................... 57
Figure 24: e-SENS WP5.2 eP/PS Summary Pilot Plan ...................................................................................... 63
Figure 25: eID flow of events .......................................................................................................................... 77
Figure 26: eID flow of events .......................................................................................................................... 90
Figure 27: Use Case Diagram ........................................................................................................................ 122
Figure 28: Overview of the eConfirmation solution ...................................................................................... 128
Figure 29: Create and deliver eConfirmation request ................................................................................... 129
Figure 30: Receive and process eConfirmation request ................................................................................ 130
Figure 31: Provisioning of the Provisional replacement certificate ............................................................... 131
Figure 32: Receive provisional requirement certificate ................................................................................ 132
Figure 33: Reference model.......................................................................................................................... 133
Figure 34: Message exchange between the corners ..................................................................................... 136
Figure 35: MSH / P-Mode configuration ....................................................................................................... 137
Figure 36: Inbound scenario – receiving a request document ....................................................................... 144
Figure 37: Outbound scenario – sending a request document ...................................................................... 145
Figure 38: Outbound scenario – receiving the response ............................................................................... 146
Figure 39: Inbound scenario – receiving a request document ....................................................................... 154
Figure 40: Outbound scenario – sending a request document ...................................................................... 155
Figure 41: Outbound scenario – receiving the response ............................................................................... 156
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 11
List of Tables
Pe
nd
in
g
EC
ap
pr
ov
al
Table 1: Abbreviations ................................................................................................................................... 18
Table 2: Differences between epSOS and STORK in the SAML 2.0 Web SSO Profile (from STORK).................. 28
Table 3: Global eP/ PS Use Case Functional Components ............................................................................... 34
Table 4: findIdentityByTraits() operation ....................................................................................................... 45
Table 5: STORK Identity Attributes Excerpt .................................................................................................... 49
Table 6: Potential re-use of established infrastructure from prior LSPs .......................................................... 59
Table 7: Other potential re-use of established infrastructure ......................................................................... 59
Table 8: BBs by problem for the eP/PS Use Case ............................................................................................ 60
Table 9: Relevance of the problem to the eHealth domain as anticipated by participating MS ...................... 60
Table 10: e-SENS 5.2.1 Pilot Plan for eP/PS .................................................................................................... 66
Table 11: eP/PS pilot plan phases................................................................................................................... 69
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 12
List of Abbreviations
Explanation
AAL
Authentication Assurance Level
ABB
Architecture Building Block
AC
Associated Country
ACo
Administrative Commission for the Coordination of Social Security Systems
AHG
eEHIC Ad Hoc Group
AP
Access Point
ATNA
Audit Trail and Node Authentication
BB
Building Block
CC
Competence Cluster
CDA R2
Clinical Document Architecture Release 2.0
CEF
Connecting Europe Facility (Regulation/Programme)
CIP
Competitiveness and Innovation Framework Programme
CS
Central Services
CTS
Common Terminology Services
DSI
ov
pr
ap
EC
g
in
Pe
nd
DS
al
Acronym
Data Sources
Digital Service Infrastructure (in the CEF)
DSP
Dossier de Soins Partagé
eD
Electronic Dispensation
EEA
European Economic Area
EESSI
Electronic Exchange of Social Security Information
http://ec.europa.eu/social/main.jsp?catId=869
eHGI
eHealth Governance Initiative
http://www.ehgi.eu/default.aspx
EHIC
The European Health Insurance Card is a portable document, which proves the
entitlement to necessary healthcare while on a temporary stay abroad (as far as the end
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 13
date is not expired).
eHN
eHealth Network
http://ec.europa.eu/health/ehealth/policy/network/index_en.htm
eID
Electronic Identity
eIDAS
Regulation on electronic identification and trust services for electronic transactions in the
internal market
EIRA
The European Interoperability Reference Architecture
https://joinup.ec.europa.eu/asset/eia/description
European Medicines Agency
ENED
ENED is a network of European Partners, aiming at servicing both European citizens,
applying for healthcare in a fellow Member State, during their temporary stay and their
healthcare provider.
pr
ov
al
EMA
http://www.ened.eu/
Electronic Prescription
ePRC
As result of a positive insurance verification, processed by the eConfirmation service, an
ePRC is provided. The ePRC dataset is identical to the PRC.
epSOS
EC
Currently the ePRC does not (yet) have a legal status
European Patients – Smart Open Services
g
and
eConfirmation
ap
eP
e-SENS
ESS
eTEN
ETSI
Entity Registries
Pe
nd
ER
in
http://www.epsos.eu/
Electronic Simple European Networked Services
Extended Security Safeguards
Trans-European Telecommunications Networks Programme
European Telecommunications Standards Institute
http://www.etsi.org/
ETSI REM
ETSI Registered Electronic Mail
EXPAND
Expanding Health Data Interoperability Services
http://www.expandproject.eu/
EU
European Union
FC
FutureID Client
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 14
FP7
Framework Programme 7
FutureID
Shaping the Future of Electronic Identity
http://www.futureid.eu/
GA
General Assembly
GINI
Global Identity Network of Individuals - Support Action
http://www.gini-sa.eu/
General Practitioner
HCP
Healthcare Provider
HCPO
Healthcare Professional Organization
HIO
Health Insurance Organization
HL7
Health Level 7 (HL7 v3: HL7 version 3)
HORIZON 2020
Horizon 2020 is the biggest EU Research and Innovation programme ever
ap
pr
ov
al
GP
http://ec.europa.eu/programmes/horizon2020/
Healthcare Provider/ Healthcare Professional
HPO
Healthcare Professional Organization
HTTP
HyperText Transfer Protocol
HVOS
HVOS (http://www.hauptverband.at) is the umbrella organization of all Austrian Social
Security Institutions and the Austrian Liaison Body for cross-border related issues.
IdA
IdP
g
in
Pe
nd
ICT
EC
HP
Information and Communication Technologies
Identity Assertion
Identity Provider
IHE
Integrating Healthcare Enterprise
IP
Intellectual Property
IPS
Institution of the Place of Stay
ITSV
ITSV (http://www.itsv.at) is a subsidiary of all Austrian Social Security Institutions and is
responsible for project management and electronic data exchange between the Austrian
HIOs
LoA
Level of Authentication
LOINC
Logical Observation Identifiers Names and Codes
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 15
Large Scale Pilot
MS
Member State
MS A
The EU/ EEA Member State of origin of the patient/ citizen and/ or MS where patient's
Health Insurance organization resides.
MS B
The EU/ EEA Member State of temporary stay of the patient and MS where he/ she
applies for healthcare according to the EU Regulation
MSH
Message Service Handler
MVC-MTC
Master Value set Catalogue – Master Translation/Transcoding Catalogue
NAP
National Access Point
NCP
National Contact Point
NCP-A/B
National Contact Point of Country A or B
NETC@RDS
NETC@RDS was an eTEN funded project, enabling the Health Practitioners to check
foreign patients' entitlement to healthcare. It is based on an agreement, so-called the
General Agreement, between Health Insurance Organisations (HIO) aiming to provide
easier access to cross-border healthcare for citizens travelling abroad but inside the
EEE/EU and Switzerland.
EC
ap
pr
ov
al
LSP
http://www.netcards-project.com/web/frontpage
National Institute of Standards and Technology
NSL
NCP-service Status List
OpenNCP
Suite of epSOS NCP software publicly available under Open Source licensing
PDP
PEP
in
Pe
nd
PAAS
g
NIST
Patient Access Authentication Service
Policy Decision Point
Policy Enforcement Point
PEPS
Pan-European Proxy Service
PN
Participating Nation
PoC
Point of Care
PPT
Pre-Production Testing
PRC
Provisional Replacement Certificate
PS
Patient Summary
PSP
Policy Support Programme
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 16
Quarter 1 (January-March)
Q2
Quarter 2 (April-June)
Q3
Quarter 3 (July-September)
Q4
Quarter 4 (October-December)
QAA
Quality Authentication Assurance
RTD
Representative Test Data
SAML
Security Assertion Markup Language
SAT
Solution Architectural Template
SBB
Solution Building Block
SDO
Standards Developing Organization
SEG
Security Expert Group
SP
Service Provider
SPOC
Single Point of Contact
SSO
Single Sign-On
STepS
STORK meets epSOS subproject of STORK 1
STORK
Secure idenTity acrOss boRders linKed
in
g
EC
ap
pr
ov
al
Q1
https://www.eid-stork.eu/
SVC
Security Token Services
Pe
nd
STS
SVC is an Austrian subsidiary of HVOS and responsible for project management and
electronic data exchange between all actors (in particular HCPs and HIOs) involved in the
healthcare sector.
TA
Technical Annex
Ten4Health
Trans-European healthcare support network for Europe’s mobile citizen
http://www.ten4health.eu/
TM
Transformation Manager
TRC(A)
Treatment Relationship Confirmation (Assertion)
TSL
Trust-service Status List
UC
Use Case
Valid EHIC
An EHIC which validity date is not expired at the moment, that healthcare is provided in a
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 17
Virtual Identity Provider
WP
Work Package
XACML
eXtensible Access Control Markup Language
XCA
Cross-Community Access
XCF
Cross-Community Fetch
XCPD
Cross-Community Patient Discovery
XDS
Cross-enterprise Document Sharing
XSPA
Cross-Enterprise Security and Privacy Authorization
Pe
nd
in
g
EC
ap
pr
Table 1: Abbreviations
ov
V-IDP
al
fellow MS
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 18
1. Introduction
1.1.
Scope and Objective of the Document
The purpose of the document (sub-deliverable D5.4-2), is to present the domain pilot plans of the
two domain use cases in the domain 5-2 eHealth, and the national pilot plans for the MS/ACs
participating in the domain. The process of defining and approving e-SENS pilots is entirely MS/AC
driven.
UC 5.2.1 ePrescription/Patient Summary

UC 5.2.2 eConfirmation of insurance entitlement
pr

ov
al
The two domain use cases that had been approved by the e-SENS General Assembly (Baarn, NL, 2526.02.2014) for starting pilots and had been initially described in deliverable D5.3-2 submitted in
M12, are the following:
ap
Domain pilot plans have been prepared for both use cases and are included in this deliverable. MS
having delivered national pilot plans in the use cases of this domain are the following:
UC 5.2.1: Spain, Greece, Italy, Luxembourg, Portugal

UC 5.2.2: Estonia, Netherlands, Poland.
EC

Structure of the Document
in
1.2.
g
Other MSs have expressed their piloting intention in the domain and are working on the preparation
of their national pilot plans.
Pe
nd
Since the two use cases of the domain are completely different, the document is structured as
follows:
Chapter 1 presents the introduction of the document.
Part I includes the UC5.2.1 ePrescription / Patient Summary domain pilot plan (Chapter 2 and
Annexes I, II, III, IV) and the national pilot plans of the MS (Spain, Greece, Italy, Luxembourg and
Portugal) that are planning to pilot in UC5.2.1 (Chapters 3, 4, 5, 6, 7).
Part II includes the UC5.2.2 eConfirmation domain pilot plan (Chapter 8) and the national pilot plans
of the MS (Estonia, Netherlands, and Poland) that are planning to pilot in UC5.2.2 (Chapters 9, 10,
11).
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 19
ov
al
Part I:
EC
ap
pr
UC 5.2.1 ePrescription / Patient Summary
Pe
nd
in
g
Domain and National Pilot Plans
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 20
2. Domain Pilot Plan of Use Case 5.2.1: ePrescription/Patient
Summary
Even if the use cases ePrescription and Patient Summary are different, their European background
and motivation in e-SENS are similar. In consequence, these two use cases have been introduced in a
common perspective but each one has a distinctive process description.
2.1.
Use case overview
al
Use case 5.2.1 describes how to support cross border care for Patient Summaries and ePrescriptions
in line with Directive 2011/24/EU on patients' rights in cross-border healthcare1.
ap
pr
ov
In the Patient Summary (PS) case, the patient is a visitor to the country of treatment, for example
someone on holiday, one attending a business meeting, or one that lives in one country but works in
another. The health professional may have some information available from previous encounters, in
which case the patient may have a patient record locally stored and possibly also a PS in the country
of origin. Both sources of information could be consulted and updated by the health professional.
Motivation and Goals
Pe
nd
2.2.
in
g
EC
In the ePrescription (eP) case the patient context is similar to the Patient Summary case, e.g., the
patient is visiting the country of treatment. If a prescribed medical product is not available abroad,
the attending pharmacist may, depending on the circumstances, dispense a different brand or
package size of a comparable product to the patient. In case of a product being dispensed, the
eDispensation document is returned to the country of affiliation, to allow the update of the
corresponding ePrescription.
e-SENS aims to enhance the cross border services originally developed in epSOS by integrating some
e-SENS generic building blocks.
2.2.1.
Background and rationale
The epSOS LSP concentrated on proving that a reliable and secure exchange of medical data in a
cross-border setting is actually possible and feasible. epSOS was co-funded by the European
Commission Competitiveness and Innovation Programme (CIP) within the ICT Policy Support
Programme. By the end of the project, up to 19 epSOS Participating Nations (PNs) launched their
1
The European Parliament and the Council of the European Union. 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
[PDF]. Strasbourg. 2011-03-09. [cited 03 March 2015]. Available from Internet: http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:088:0045:0065:en:PDF
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 21
epSOS pilots2. While fully achieving its primary goal as well as establishing a new eHealth ecosystem
throughout the European Member States and affiliated participating nations, it became apparent
that several supporting functionalities and services might be improved by already existing or
currently developed tools and means, that may be used on different domains, provided they can
adequately deliver an assertive solution for healthcare use cases and scenarios.
The epSOS architecture focuses on the exchange of medical data in two primary use case settings:

Patient Summary.

ePrescription and eDispensation.
Ancillary value added services were implemented and piloted on top of the two primary use cases:
Patient Access: for patients accessing and reviewing their own medical data, displayed in
different languages.

Healthcare Encounter Report: for relaying medical findings back into the home country.

Medication-related Overview: for providing a quick reference of current medication.
pr
ov
al

EC
ap
Both, the primary use cases as well as the value-added services primarily feature clinical challenges.
However, substantial parts of the non-functional requirements in particular regarding data
protection, confidentiality, and information-security aspects, had to be specifically approached by
the eHealth domain, since none of the – at the time available solutions – provided effective answers
to the challenges faced by the eHealth Domain that could fit for the purpose of cross border care
services.
Pe
nd
in
g
One principle example is the duplication of work regarding the entity identification, authentication,
and authorization between epSOS and typical eGovernment initiatives such as STORK and FutureID3.
Despite of the requirements of eGovernment and eHealth regarding electronic identities and
identification are targeting the same goal, domain specific security requirements discouraged the
adoption of eID at that time.
Ad-hoc collaboration between the epSOS and the STORK LSP, called STepS, revealed a significant
potential of both initiatives complementing each other alongside with a very beneficial side effect of
implicitly consolidating the solutions towards common basic infrastructure for shared tasks. The new
specifications of STORK 2.0 are now allowing a realistic re-use of concepts and blocks. Other related
activities, such as the German epSOS Extended Security Safeguards (ESS) or the current work within
FutureID, are also targeted at consolidating the common tasks and responsibilities in a cross-domain
fashion.
2
19 PNs ran the EU wide pilot in pre-production, to exchange clinical test data, 16 of them also activated the
pilot for real patients.
3
FutureID is an Integration project partially funded under the ICT theme of the Cooperation Programme of the
7th Framework Programme of the European Commission which builds a comprehensive, flexible, privacy-aware
and ubiquitously usable identity management infrastructure for Europe.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 22
2.2.2.
Value and domain importance
The eHealth domain would greatly benefit from mitigating non-domain concerns, such as eID, trust
anchors, trust bootstrapping, crypto-management, and baseline infrastructure security towards
other domains that are authoritatively responsible of providing those exact measures. Even so, deep
assessment MUST be made in order to deeply understand the legal, organizational, semantic and
technical interoperability framework that has been establish for the last fifteen years in Europe as
well as around the world. Such assessments may provide evidence that what in principle are nondomain concerns (e.g. baseline infrastructure) may in fact be tightly tied to domain requirements or
pre-conditions (e.g. metadata profiling).
The eHealth domain and its services may benefit through:
a substantial reduction in duplication and, in perspective of complexity of eHealth eID
solutions through the injection of cross-sector common technology,

a significant reduction of time-to-market and ownership efforts for implementing, deploying,
and maintaining secure eHealth infrastructures and services,

measurable increases in patient-data availability in unplanned scenarios leading to better
patient safety,

the deposition of non-domain concerns towards authoritatively responsible entities,

the ability to seamlessly codify cross-domain aspects such as univocally appoint a patient’s
legal guardian or the inclusion of reimbursement aspects, and

a higher degree of compliance to advancing regulatory concerns such as patient-controlled
access, data mobility, and patient supervision.
g
EC
ap
pr
ov
al

in
The responsible entities for common eID may benefit through:
a wider base of potential users with comparably large number of permanent episodes,

a significant advance in commonalities and applicability of the currently evolving eID
solutions, such as marrying eGov, eHealth, and eBusiness concerns, and

a substantial reduction in technology redundancy, innovation, and incompatibility in crossborder/ cross-domain services.
Pe
nd

Patients may also benefit through:

the operation of commonly used and available identification material, such as identity cards,
passports, mobile ID’s, etc.,

the reduction of required identity token to bring to a treatment episode especially abroad,
and

the facilitation of innovative services that are accessible for the patient from any place.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 23
2.2.3.
Specific relationship with prior LSPs or other domain
initiatives
2.2.3.1. Smart Open Services for European Patients (epSOS)
ap
pr
ov
al
The use cases are primarily based on the existing epSOS technology and architecture and rely heavily
on the already anticipated and integrated anchor points for an external eID injection into the epSOS
specifications. The fundamental epSOS architecture is depicted in Figure 1.
EC
Figure 1: Fundamental epSOS Architecture
Pe
nd
in
g
The central portion of Figure 1 signifies the heart of the epSOS architecture: the National Contact
Points (NCP). Those systems are deployed by each active participating nation and serve as the
primary contact to each MS. Their duties and responsibilities are described in the epSOS Legal
Sustainability Recommendations. The NCPs are furthermore anchor points for cross-border
interoperability as their exposed interfaces are commonly agreed upon by all e-SENS participants.
The NCPs also serve as trust anchors, brokers (although exclusively trusting their own actors) and
bootstrapper (through MS agreements an existing regulation) as well as serving as specific entry/exit
points for applicable legislation and jurisdiction. The right-hand side shows the country of affiliation
or country-A, representing the primary data location of the patient as well as the provision points for
the epSOS business services, such as Patient Summary and ePrescription. These services and the
connected national infrastructure of country-A provide the information on patients and can
unambiguously identify them.
The left portion hosts the infrastructure and systems of the country of treatment (or country-B) as
well as any affiliated healthcare professional including their local health IT. In the epSOS use cases,
the patient is always physically present in country-B while the patient data is mostly residing in
country-A at the time of data exchange.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 24
Figure 2: epSOS Architecture Stack
pr
ov
al
The top-most layer of the epSOS architecture stack is the epSOS Semantic Framework. Through the
concept of semantic signifiers, the epSOS Semantic Framework provides data consumers and data
producers with end-to-end semantics: the data consumer receives medical information with the full
semantics as intended by the data producer. Semantic services of the epSOS Semantic Framework
provide usability-enhancing and patient-safety-enhancing services on top of epSOS shared medical
documents. The exchanged documents are HL7 CDA v2 Level 3 documents, structured and coded.4
EC
ap
The epSOS B2B Document Sharing Platform provides services for implementing the epSOS business
patterns. It does so in a B2B manner and therefore is only defined within the epSOS space (which is
NCP-to-NCP). epSOS participating nations MUST provide functionality within their NCPs to connect
the epSOS Document Sharing Platform to their existing national data sharing platforms.
in
g
The epSOS Security and Privacy Safeguards provide means for encoding and sharing security
assurances. In addition this architectural layer implements security services for providing a sufficient
level of confidentiality, integrity and non-repudiation to epSOS. Depending on the communicating
countries abilities and requirements, all security safeguards and services can either be implemented
end-to-end or be brokered by the countries NCPs.
Pe
nd
The epSOS NCP-to-NCP Connectivity layer spans a private communication network among NCPs and
provides functionalities for epSOS service discovery. It links epSOS Central Services to the epSOS
network and provides means for synchronizing local NCP configuration data from epSOS Trusted
Service Lists and globally managed terminologies.
The epSOS layered architecture with an end-to-end semantic framework on top of a contentagnostic, NCP-to-NCP platform perfectly matches with the design pattern of a service facade. With
4
The Patient Summary is compliant to the EC Guidelines:
European Commission. Guidelines on minimum/non-exhaustive patient summary dataset for electronic
exchange in accordance with the cross-border Directive 2011/24/EU [PDF]. Version 1.0. 2013-11-19. [cited 03
March
2015].
Available
from
Internet:
http://ec.europa.eu/health/ehealth/docs/guidelines_patient_summary_en.pdf
The detailed specification of document syntax, semantic, data sets and value sets for Patient Summary and
ePrescription that will be piloted in e-SENS are provided in epSOS. D3.9.1, Appendix B1/B2: “epSOS Semantic
Implementation Guidelines” [paper]. Version V1.4. 2011-07-25.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 25
this pattern the functional and semantic diversity of different services is hidden behind a simple and
generic interface.
Pe
nd
in
g
EC
ap
pr
ov
al
epSOS makes use of this pattern in a way that the NCP-terminated document sharing platform acts
as a facade to the epSOS business services which are bound to different semantic signifiers. By these
services, which implement e.g. the semantic signifiers “ePrescription” and “Patient Summary” can be
reached by a common interface while nevertheless allowing for a specific handling of requests
according to the specific semantics of the semantic signifier. E.g. a data request for an ePrescription
can be implemented as “provide me with all active prescriptions of the patient” while a data request
for a patient summary can be implemented as “provide me with the currently valid patient summary
of the patient”. In this example, the different end-to-end agreed semantics of “active” and “valid”
are implemented by services, which can be reached through a common interface at the NCP facade.
Figure 3: epSOS NCP-to-NCP Interaction Patterns
As shown in Figure 3, the epSOS Application Architecture solely defines the patterns for NCP-to-NCP
communication. These modular patterns encapsulate all flows of control and data among NCPs which
are needed to implement the NCP-to-NCP portion of end-to-end, cross-country interaction among
healthcare professionals and other business entities. The connectivity from such business entities to
NCPs is within national concern.
The epSOS Application Architecture Specification defines the logical perspective onto cross-border
data sharing. It is fully content-agnostic and therefore its design can be re-used for any existing and
future epSOS information dimension specification.
The normative parts of the epSOS Application Architecture Specification are located in the
computational dimension which is rather streamlined:

the Service Architecture Definition provides the logical specification on how epSOS core
patterns and principles are mapped on the architecture design;
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 26

epSOS Communication Pattern specify the logical flow of control and data among NCPs
(dynamic model);

epSOS Service Contract Specifications specify the logical interfaces of epSOS services that
face into the epSOS domain (static model).
2.2.3.2. STORK
In a nutshell, STORK provides an interoperability framework for eID natural person authentication in
online processes (including a limited set of attributes often coming with eID tokens, like name, date
of birth, or address); STORK 2.0 extends by representation and mandates, and an enriched set of
attributes through attribute providers. The interoperability framework is based on SAML 2.0.
pr
ov
al
The high-level STORK and STORK 2.0 process is that authentication is always delegated to the
citizens’ “MS-A” infrastructure (this is either a MS-A infrastructure component “PEPS” or a
decentralized software component “V-IDP”. The two deployment models “centralized PEPS”/
“decentralized V-IDP” are a MS decision, its differences are not discussed here, as they are anyhow
compatible). For the Service Provider, authentication requests get routed through “MS-B”
components (again V-IDP or PEPS depending on the MS deployment choice).
EC
ap
STORK is meant to be sector-independent. It however emerged from an eGovernment background.
In order to ease applicability in the eHealth domain, a STORK-epSOS liaison activity “STepS” has been
carried out in STORK already; it got intensified in STORK 2.0 by defining a dedicated eHealth pilot
addressing patient identification and attribute provision.
Pe
nd
in
g
The STepS experience already showed neat similarities in using SAML 2.0 by both, and on the
conceptual level and, like using national gateways “NCP” in epSOS and “PEPS” in STORK, as illustrated
in Figure 4 (for sake of simplicity, the STORK ”middleware “ model using V-IDPs is not shown. The
difference is less relevant, in essence “middleware-countries” have a decentralized deployment
instead of a centralized PEPS).
epSOS
NCP (MS A)
NCP (MS C)
Circle of Trust
NCP (MS B)
NCP ...
STORK
PEPS (MS A)
Circle of Trust PEPS (MS B)
PEPS (MS C)
PEPS ...
Figure 4: Circles of Trust (from STORK)
STepS however also revealed some differences, like SAML 2.0 protocol choices. The main differences
are shown in Table 2. Some relate to established legacy in the two core domains eGovernment and
eHealth, some originate from differences in core business processes. Overcoming those differences
seems however not too complex technically and can be achieved without interfering with the core
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 27
protocols of either of the two LSPs (like with SAML gateways). It is however worth considering that
work on identifying such differences exists.
epSOS
STORK
HTTP-Post Binding
AuthnRequest/Response protocol (Only in Tiani NCP
and OpenNCP portal backend implementation)
AuthnRequest/Response protocol
Only Assertion signed
Both protocol messages signed
Use of SAML Authentication Context Classes
QAA Level instead of Authentication Context Classes
Use of SAML metadata (Only in Tiani NCP)
Proprietary metadata
al
HTTP-Post Binding (Only in Tiani NCP)
ov
Table 2: Differences between epSOS and STORK in the SAML 2.0 Web SSO Profile (from STORK)
Given this overall STORK and STORK 2.0 functions, different eHealth use cases can be distinguished:
STORK in country B: STORK can augment existing epSOS patient identification, as the
patient’s eID tokens can provide a high level of assurance of patient’s unique identification.
Traits can be augmented through STORK and STORK 2.0 attribute provision. (Note that using
STORK on PoC environments give a challenge, like with card-based eID).

STORK in country B: Patient access relates to the “core” STORK business process. The patient
uses her IT environment to authenticate at the eHealth SP (whether it is an NCP or a
healthcare professional).
EC
ap
pr

Pe
nd
in
g
Operating STORK at a PoC is challenging, if eID tokens have requirements on the IT environment, like
card readers, drivers, etc. Mobile eID can play a major role to overcome that. While STORK itself is
agnostic to the actual eID credential, the ubiquitous nature of mobile phones together with its zerofootprint characteristic (not imposing requirements on the computing environment other than e.g. a
browser), may allow use at a PoC.
2.2.3.3. FutureID
The FutureID project builds a comprehensive, flexible, privacy-aware and ubiquitously usable identity
management infrastructure for Europe, which integrates existing eID technology and trust
infrastructures, emerging federated identity management services and modern credential
technologies to provide a user-centric system for the trustworthy and accountable management of
identity claims.
The FutureID infrastructure will provide great benefits to all stakeholders involved in the eID value
chain. Users will benefit from the availability of a ubiquitously usable open source eID client that is
capable of running on arbitrary desktop PCs, tablets and modern smart phones. FutureID will allow
application and service providers to easily integrate their existing services with the FutureID
infrastructure, providing them with the benefits from the strong security offered by eIDs without
requiring them to make substantial investments.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 28
This will enable service providers to offer this technology to users as an alternative to
username/password based systems, providing them with a choice for a more trustworthy, usable and
innovative technology. For existing and emerging trust service providers and card issuers FutureID
will provide an integrative framework, which eases using their authentication and signature related
products across Europe and beyond.
To demonstrate the applicability of the developed technologies and the feasibility of the overall
approach FutureID will develop two pilot applications and is open for additional application services
who want to use the innovative FutureID technology.
2.3.
Process Description: Patient Summary
Actors
pr
The following actors compose the e-SENS use case for PS:
ov
2.3.1.
al
This section introduces the patient summary flow as defined by epSOS. Additional information on its
quality metrics will be found in the epSOS deliverables (D3.7.2, D3.A.x) and will not be reported here.
A patient/citizen, who is seeking for healthcare treatment abroad

A healthcare professional or provider, who is providing healthcare treatment. The healthcare
professional is in the need to access remote patient electronic health record using the
National Infrastructure

Two National Contact Points and the epSOS Central Services for NCP configuration and
Terminology handling

Providers of trusted sources including national registries of citizens, patients and health
professionals
2.3.2.
Pe
nd
in
g
EC
ap

Preconditions
The following conditions must be met before the PS use case can start

Α patient/ citizen requesting a healthcare professional for medical assistance abroad
(Country B)

A PS must exist in the patient/ citizen’s country of origin (Country A)

The healthcare professional is a person legally authorised in Country B to provide healthcare
and is identified and authenticated in Country B

A mechanism to validate the identity of the patient at the Point of Care has to be available

The health professional at Country B knows the identity of Country A

A health professional must be related to at least one HPO or to a Health Authority.

The patient/ citizen MUST provide consent (previously given or during the encounter) to the
healthcare professional before health data is exchanged
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 29

There is a chain of trust between system actors in this process

The health professional must be able to access the “communication layout” that handles the
PS in the European Countries
2.3.3.
Flow of events
The use case begins when a healthcare professional in Country B receives a request for healthcare
assistance from a patient/ citizen from Country A
1. Patient is identified
2. The health professional requests the validation of the identity of the patient
al
3. The request is conveyed to the patient’s country of origin (Country A)
4. Country A provides the (positive or negative) patient’s identification confirmation.
ov
5. Country A provides the patient’s identity and consent confirmation to the health professional
pr
6. Once the identity of the patient is validated, the patient consent is verified
ap
7. Once the identity of the patient is validated, the healthcare professional of Country B
requests for the PS of Country A
8. If the PS exists, Country A provides the PS of Country A to the health professional.
Post-conditions
g
2.3.4.
EC
9. The PS of the patient/ citizen seeking for healthcare treatment abroad is displayed to the
health professional.
Pe
nd
in
If all the pre-conditions are met then the healthcare professional of Country B can have access to the
PS of the patient in Country A.
If the identity of the patient cannot be properly validated in Country A then Country A informs
Country B, and subsequently the healthcare professional of the identification failure.
If the PS of the patient does not exist or cannot be retrieved from Country A then Country A informs
Country B, and subsequently the healthcare professional of the failure.
2.3.5.
Assumptions
Physicians are involved to generate high quality clinical documents and assess their correctness.
2.3.6.
Special requirements
For the purposes of running the pilots with real patients, it is considered essential that requirements
be included in bilateral or multi-lateral agreements between partnering MS and their appropriate
inclusion be verified by e-SENS in order to maintain convergence. For real patient’s health data to be
exchanged there is also the strong binding LEGAL requirements (e.g. like the epSOS Legal Framework
Agreements).
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 30
2.4.
Process Description: ePrescription/ eDispensation
This section introduces the ePrescription flow as defined by epSOS. Additional information on its
quality metrics will be found in the epSOS deliverables (D3.7.2, D3.A.x) and will not be reported here.
2.4.1.
Actors
The following actors compose the e-SENS use case for ePrescription/ eDispensation (eP/ eD):
A patient/ citizen, who is seeking for having a medical product dispensed abroad

A pharmacist who is on duty to dispense the prescribed medical product. The pharmacist is
in the need to fetch the remote ePrescription document record using the National
Infrastructure, and to submit the corresponding eDispensation, once the medicine is
dispensed

Two National Contact Points and the epSOS Central Services for NCP configuration and
Terminology handling

Providers of trusted sources including national registries of citizens, patients and health
professionals
2.4.2.
ap
pr
ov
al

Preconditions
EC
The following conditions must be met before the eP/ eD use case can start
Α patient/ citizen requesting a pharmacist for having a medical product dispensed abroad
(Country B)

A valid for dispensation ePrescription document must exist in the patient/ citizen’s country
of origin (Country A)

The pharmacist is a person legally authorised in Country B to dispense medical product and is
identified and authenticated in Country B

A mechanism to validate the identity of the patient at the pharmacy has to be available

The pharmacist at Country B knows the identity of Country A

The patient/ citizen MUST provide consent (previously give or during the encounter ) to the
healthcare professional before health data is exchanged

There is a chain of trust between system actors in this process

The pharmacist must be able to access the “communication layer” that handles the
ePrescription documents in the European Countries
Pe
nd
in
g

2.4.3.
Flow of events
The use case begins when a pharmacist in Country B receives a request for having prescribed a
medical product from a patient/ citizen from Country A, who owns an ePrescription
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 31
1. Patient is identified
2. The pharmacist requests the validation of the identity of the patient
3. The request is conveyed to the patient’s country of origin (Country A)
4. Country A provides the (positive or negative) patient’s identification confirmation.
5. Country A provides the patient’s identity and consent confirmation to the pharmacist
6. Once the identity of the patient is validated, the patient consent is verified
7. Once the identity of the patient is validated, the pharmacist of Country B requests for the list
of valid ePrescription documents of Country A
8. If the ePs exist, Country A provides the list of ePs of Country A to the pharmacist.
10. The pharmacist dispenses the medical product
pr
11. The pharmacist generates eD
ov
al
9. The pharmacist selects the requested eP, accesses to the eP of the patient/ citizen seeking
for having the medical product dispensed abroad.
Post-conditions
EC
2.4.4.
ap
12. The eD document is transmitted using the NCP to Country A
If all the pre-conditions are met then the pharmacist of Country B can have access to the eP of the
patient in Country A and submit an eD, to Country A.
in
g
If the identity of the patient cannot be properly validated in Country A then Country A informs
Country B, and subsequently the pharmacist of the identification failure.
Pe
nd
If the eP of the patient does not exist or cannot be retrieved from Country A then Country A informs
Country B, and subsequently the pharmacist of the failure.
If the eD document is not successfully submitted to Country A, then Country A informs Country B,
and subsequently the pharmacist of the failure
2.4.5.
Assumptions
Physicians are involved to generate high quality clinical documents (eP) and assess their correctness.
2.4.6.
Special requirements
For the purposes for running the pilots with real patients, it is considered essential that requirements
be included in bilateral or multi-lateral agreements between partnering MS and their appropriate
inclusion be verified by e-SENS in order to maintain convergence. As well as in the PS use case the
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 32
LEGAL requirements are crucial to assure the usage of real patient data. There is also the need to
assure compliance with the ePrescription EU guidelines agreed at the end of 20145.
2.5.
Architecture and Use of Building Blocks
2.5.1.
Overview diagram of architecture and topology
pr
ER
ap
EC
National
Contact
Point
in
Non HPO
Environment
Citizen
FutureID
Client
Browser
NCP-A
Infrastructure
Web
Service
Web
Service
Web
Service
Pe
nd
epSOS
Infrastructure
Data Source
STORK
Abstraction Layer
g
NCP-B
Infrastructure
National
Contact
Point
Patient Regi stry
Web Service
Country B
National
Infrastructure
Country B
TM
Abstraction Layer
Point of Care
Abstraction Layer
Portal
Trusted
HPO
Environment
Browser
FutureID
Client
WebService
Service
Web
Service
Web
TM
Trusted
HPO
Environment
Abstraction Layer
ER
STORK
Portal
ov
al
Figure 5 outlines an overall overview of the e-SENS eHealth infrastructure by extending the existing
epSOS solution architecture with supplemental components provided by e-SENS as well as the
systems topology by defining the interrelations and orchestration of the supplements. The newly
integrated components are highlighted in orange and only feature their most common integration
means (such as a Web Service or user agent) for improving the readability of the diagram.
National
Infrastructure
Country A
FutureID AIS
Patien Access Portal
epSOS
Patient Data
Source
HPO
Environment
Country A
Figure 5: Global eP/ PS Use Case Architecture
The global architecture is comprised of the functional components listed on Table 3.
Component
Description
FutureID Client
The FutureID Client is a component designed to operate within the User Agent (such as
5
European Commission. Guidelines on ePrescriptions dataset for electronic exchange under Cross-Border
Directive 2011/24/EU [PDF]. Release 1. 2014-11-18. [cited 03 March 2015]. Available from Internet:
http://ec.europa.eu/health/ehealth/docs/eprescription_guidelines_en.pdf
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 33
a Web Browser) at the Point of Care or the citizen’s IT. Its primary functionality is to
extend the capabilities of formerly incompliant IT towards the application of advanced
eID, trust, and security functionality directly within the realm of the user.
The STORK back-end is depicted as a component within the national infrastructure of
the respective countries. The functionality and provision of eID functionality of the
FutureID client is immediately supported by the existing services of STORK. Any STROKintrinsic interactions between the countries are performed over the existing STORK
backbone and therefore not depicted within the diagram.
TM
The Transformation Manager deals with the transcoding and translation of information
embedded in the clinical documents.
ER
The Entity Registries (ER) provide directory services towards the stakeholders, such as
identity / property information about a health professional or patient. The ER includes
the specific registers, such as the Patient or Health Professional Registry as well as the
meta directory services that combines and provides the services of multiple local
registries for a common data access.
Abstraction Layer
The Abstraction Layers are pieces of system integration facilitators that bridge the gap
between legacy backend systems and the e-SENS eHealth solution.
Environments
The environments delimit the regulatory protected realms of the stakeholders with
“Trusted HPO” environments benefitting from special legal protection (for instance
professional discretion and confiscation protection).
Data Sources
The Data Sources (DS) accommodate the clinical data repositories of a country.
g
EC
ap
pr
ov
al
STORK
Common interaction patterns
Pe
nd
2.5.2.
in
Table 3: Global eP/ PS Use Case Functional Components
The Patient Summary and ePrescription/eDispensation use cases are based on two generic
interaction patterns. The primary interaction for exchanging a patient summary is the “Request of
Data” pattern, in which a healthcare professional within country A is requesting a singular currently
active instance of a clinical document, such as a single patient summary from country-A.
HP at PoC
(Country-B)
HP at PoC
(Country-A)
(1) prepare-and-register( data, ... )
(2) query-data( searchStruct )
(3) provide-data( data, metadata )
country-B-data-consumer
country-A-data-controller
country-A-data-producer
Figure 6: Request of Data Interaction Pattern
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 34
Whenever a larger/ selective number of documents or instances are requested or different versions
of medical data are available that still preserve clinical value, the rather simplistic “Request of Data”
interaction pattern is unable to accommodate this request efficiently and effectively. Therefore, a
second interaction pattern is established that enables the healthcare professional to selectively
request a subset or collection of medical documents: “Request Overview and Pick Details”. Using this
pattern, the healthcare professional in country-B is firstly requesting an overview about all available
medical documents about a particular patient and is then able to selectively retrieve the currently
relevant. This interaction pattern usually applies more to ePrescriptions as those traditionally are
provided as multiple atomic clinical documents.
HP at PoC
(Country-B)
HP at PoC
(Country-A)
al
(1) prepare-and-register( data, ... )
ov
(2) query-overview( searchStruct )
(3) assemble overview report
pr
(4) provide-overview( report, metadata )
(6) retrieve-data( dataIDs )
EC
(3) provide-data( data, metadata )
ap
(5) select data
country-B-data-consumer
country-A-data-producer
g
country-A-data-controller
in
Figure 7: "Request Overview and Pick Details" Interaction Pattern
HP at PoC
(Country-B)
Pe
nd
The eDispensation use case, although tightly linked to the ePrescription for being its successor, is
based on the “Provisioning of Data” interaction pattern, enabling the healthcare professional in
country-B to submit medical information to country-A, as depicted in Figure 8.
E.g. HP at PoC
(Country-A)
(1) submit-data( data, metadata )
(2) acknowledge / reject
(3a) pull-data( ... )
(3b) push-data( data, ... )
country-B-data-producer
country-A-data-controller
country-A-data-consumer
Figure 8: “Provisioning of Data” Interaction Pattern
Based on those three generic interaction patterns, the full context of the operations is consolidated
into the “Application Architecture” Interaction Pattern.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 35
country-B-dataconsumer
NCP-A
(Fetch Document Service)
NCP-B
Discover and fetch PS
data; transform to epSOS
Friendly Format
(2) fetchDocumentRequest( pid= 456 , semSig= PS ,
format= epSOS )
(1) request data( pid= 456 , semSig= PS )
country-A Data Source
Semantic Services:
Transcode / Translate
(3) fetchDocumentResponse( PS-document )
Semantic Services:
Transcode / Translate
al
(4) provide data( document )
ov
Figure 9: “Application Architecture” Interaction Pattern for Medical Data Exchange
country-B-dataconsumer
ap
pr
Figure 9 is depicting requesting and receiving a Patient Summary based on the interaction pattern as
shown in Figure 6, while Figure 10 elaborates on the retrieval of an ePrescription based on the
“Request Overview and Pick Details” use case, illustrated in Figure 7.
NCP-B
country-A
eP data base
Discover eP and
assemble eP list;
transform to epSOS
Friendly Format
EC
(1) request data( pid=“456“,
semSig=“ePList“ )
NCP-A
(Data Fetch Service)
(2) fetchDataRequest( pid=“456“, semSig=“eP“,
format=“epSOS“)
(2a) query( “456“, “eP“, “epSOS“)
Pe
nd
in
g
XCA
(3) provide data( ep overview report )
(2b) eP Metadata
XCA
Semantic Services:
Transcode / Translate
Semantic Services:
Transcode / Translate
Assemble eP Overview
Report from Metadata
Display eP Overview and
select eP for Dispensation
(4) request data( pid=“456“, doc=“17“ )
(5) fetchDataRequest( pid=“456“, doc=“17“)
Discover document and
transform to epSOS
Friendly Format
(5a) retrieve( “17“)
XCA
(6a) document No.17
XCA
(6) fetchDataResponse( eP No.17 )
(7) provide data( eP No.17 )
Semantic Services:
Transcode / Translate
Semantic Services:
Transcode / Translate
Figure 10: “Application Architecture” Interaction Pattern for ePrescription
The unique eID for the patient, returned by the eID Provider MUST be recognised by NCP-A, and the
National eHealth infrastructure, as a valid trait to univocally identify a patient. This implies the full
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 36
alignment between eID Provider of the Country with the eHealth Service Provider of the same
Country.
2.5.3.
Use of e-SENS BBs per area
The following sections detail the application and implementation of e-SENS Building Blocks regarding
this use case. If a building block is taken and operated as-is, only a brief reference is stated. However,
if an existing building block is extended towards its coverage of capabilities or functionality, the
newly provided functions are laid out in sufficient detail in this document and further specified in the
detailed implementation guide of the use case itself.
2.5.3.1. Non-Repudiation
ov
al
The [D6.2 non-repudiation aspects in 4 corner models]6 defines how and where evidences for
traceability and reconstruction for transactions that process protected health information are
captured and documented. This pilot use case aligns its Audit trail to the provision set forth by the eSENS BB “Non-Repudiation”.
ap
pr
Non-repudiation services are mandated to generate, collect, maintain, make available and validate
evidence concerning a claimed event or action in order to resolve disputes about the occurrence or
non-occurrence of the event or action.
Pe
nd
in
g
EC
Non-repudiation aspects in four-corner model are not a trivial task. ISO 13888 defines four types of
non-repudiation tokens, namely non-repudiation of origin, of receipt, of delivery, and of submission.
These tokens (or evidence) are not used in the same way for all the sectors. In fact, non-repudiation
of delivery and submission are defined where delivery agents are used (e.g., store-and-forward
message exchange pattern). Moreover, "… in a four-corner model, one of the features of gateways
(corners 2 and 3) is that they can transform content (format, coding systems, enveloping structures
etc.). Corners 3 and 4 are not required to be able to interpret the content of the original sender.
Corner 4 is not required to be able to interpret the content of Corner 2".
In the eHealth use case, non-repudiation aspects are covered by the usage of ATNA audit trails, as
non-repudiation of receipt and origin tokens. However, these measures are not sufficient to fulfil the
requirements set by non-repudiation protocols, both from industry- and academic-practices. The
document epSOS D1.4.10 Report 3: on Non-repudiation (Security Expert Groups) of the 3/9/2014
defines:
The epSOS means on Audit Trail and Non-Repudiation have been established with the scope and
needs of a LSP in mind:

avoidance of any immediate implementation burden for the piloting Member States

isolation from existing national solutions including non-exposed national infrastructure
6
The electronic part of the e-SENS deliverable D6.2 (EIRA) can be found at:
http://wiki.ds.unipi.gr/display/ESENS/WP6+-+Building+Blocks. EIRA is a dynamic WIKI, which means that it will
be updated while in review, therefore it is important to note the version of an artefact when referenced. 201503-03.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 37

data source for evaluation purposes, namely the epSOS Automatic data Collector

strong separation between the concerns of the MS involved in the medical exchange:
o
epSOS Country A is protecting the concerns of its assigned patients
o
epSOS Country-B is protecting its health professionals and treatment context
Those operating principles have been gradually refined for the phase-II of the epSOS pilots but may
not be sustainable outside of a pilot operation. The epSOS Security Experts Group and the e-SENS
technical working packages were therefore tasked to:
transfer and exploit the knowledge and lessons learned from the epSOS pilots

gather and evaluate real-world data on shortcomings of transposing epSOS technology

inventarise, assess, and select appropriate technology to address the open issues

streamline formerly disparate technology into a common approach usable by all sectors
ov
al

EC
ap
pr
Content of non-repudiation tokens is defined to be sector-specific, and not to be defined projectwide. Thus, the non-repudiation chapter of D6.2 sets a XACML-based interoperability framework that
defines formally a set of rules triggered when a specific transaction takes place. For example, when
an ePrescription fetch transaction hits the NCP, the e-SENS XACML-based framework detects the
type, and evaluates a policy containing the specific rule used to emit the corresponding ATNA audit
trail.
Pe
nd
in
g
These rules can be added to enrich the non-repudiation aspects of the NCP as stated in the SEG
report. ETSI REM evidence is used by all the other sectors participating in e-SENS. EHealth shall
leverage the e-SENS goal to adopt ETSI REM in order to enhance (not to modify) the actual epSOS
pilots, by adopting the e-SENS non-repudiation framework. The chapter already contains working
XACML policies that emit both ATNA audits and ETSI REM evidence. Such evidence is mapped already
to the relevant non-repudiation tokens for epSOS transactions.
The adoption of the framework has been proven working in NCP environments since it is highly
inspired from the piloted epSOS Extended Security Safeguards. An implementation strategy is
sketched in the chapter.
2.5.3.2. Trust Establishment
Trust establishment is a key task both during bootstrapping and operational stages. In epSOS trust
establishment is implemented by using TSLs and NSLs containing remote certificates chains used to
validate security means (e.g., validating SAML assertions, mutual authentication on TLS channels).
During the epSOS operations, the SEG provided relaxation and amendments to the original epSOS
specifications, due to the impossibility to find suitable certification authorities able to issue the
required certificates.
In this scope, the e-SENS Trust Services SAT aims at providing a specification for cross-border and
cross-sector trust establishment and certificate layouts following the eIDAS regulation. At the time of
writing the SAT is not finalized. Once done, its findings will enable the eHealth domain to overcome
the abovementioned relaxations and align to the eIDAS.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 38
2.5.3.3. eSignatures
This pilot use case requires more advanced electronic signature facilities that exceed the capabilities
of the technical systems provided by epSOS. Consequently, the consolidated BB of e-SENS regarding
eSignatures that combines functionality of STORK, FutureID as well as the current regulatory reality
set forth by eIDAS is completely replacing the original capabilities. The building block eSignatures
may provide:

assertion and authenticated attribute signatures

time stamp signatures for Non-Repudiation

optional document signatures as currently assumed required by some piloting nations.
al
2.5.3.4. Metadata Locator Service
ap
pr
ov
epSOS is using Central Services. The Service Metadata Locator (component from PEPPOL) can be
exploited to evolve the epSOS Central Services rationale (architecture and services) by adopting eSENS Building Blocks or BB features such as Capability Lookup and Service Location. This step will
have impact also at NCP level where refactoring will need to be made in order to allow the improved
articulation model between NCPs.
2.5.3.5. eID
in
g
EC
Although the original epSOS components charged with the processing of manual as well as electronic
identification have been designed to be replaced by more appropriate and robust means, a postalignment of the subsequent healthcare standards, profiles, and interaction patterns is advisable.
While this alignment primarily serves the technical domain as well as carrying towards a more robust
provision of data protection aspects, some extremely notable side effects with benefits for the
piloting nations are anticipated:
In cases in which the “global” patient identifier of a particular patient is returned
immediately or is automatically matched to the national equivalent through the eID means,
the epSOS-internal patient identification workflow may be completely skipped.

The regulatory burden of a positive and correct patient identification and unambiguous
linkage of data is currently an organizational burden of the treating healthcare professional
who is required to confirm the identity material as presented by the patient as well as the
integrity of the link between that material and the patient referenced in the returned
medical data.

The proper provision and application of the highly diverging identification means is a
fundamental prerequisite of any successful and meaningful exchange of medical data.
However, this operational burden is currently absorbed by the treating healthcare
professional, despite their unfamiliarity with the various national means of identification. eID
may relief the healthcare professional of this burden and consequently remove a significant
obstacle towards user acceptance.
Pe
nd

D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 39

In addition to pure delivery of eID, most token carrier and national eID means support
advanced security safeguards, including the generation of cryptographic session/transaction
keys or pseudonyms. Those may be applied to the healthcare transactions to raise the overall
confidentiality as well as putting the data subject in a position to effectively exercise the
rights granted under the respective national and pan-European legislation.
al
The means for establishing a robust patient identification within epSOS rely on several technological
and organisational prerequisites originally designed and specified in order to accommodate national
specialties, unavailability of suitable technology, and the former absence of pan-European
procedures to identify and authenticate patients in a cross-border scenario. The e-SENS building
block “eID” is set to overcome the inefficiency and merely fundamental robustness of the original
epSOS process by establishing the means to operate purely electronic identification for not only
identifying but ideally authenticating patients for the clinical workflows, while preserving a full
compatibility with the existing epSOS technology.
ap
pr
ov
The eIDAS Regulation aims at boosting the user convenience, trust and confidence, while keeping
pace with technological developments, promoting innovation and stimulating competition. Following
the formal adoption of the Regulation, related delegated/implementing acts will be developed. This
will be accompanied by the necessary policy, standardisation and communication activities at the EU
and International levels to ensure understanding and a positive environment for the acceptance and
wide uptake of the new legislative framework.
g
EC
This includes the leveraging of the large scale pilots (like STORK, SPOCS, PEPPOL, eCodex, epSOS) as a
pillar for the development of interoperability of cross-border eID and trust, by identifying and using
appropriate mechanisms to develop and engage "communities" – citizens and SMEs in particular - in
promoting the use and uptake of eID and trust services.
Pe
nd
in
It will also help bridge the eIDAS Regulation and technical/innovation projects (under existing and
future programmes, i.e. CIP, FP7, Horizon 2020 and CEF) with relevant non-EU Governmental and
private-sector led initiatives with a view to drive innovation at global level and increase the market
and social growth opportunities for European stakeholders. It will also make a follow-up of the
existing legislative framework (currently Directive 1999/93/EC and, upon formal adoption, the eIDAS
Regulation). This includes managing the legal proceedings related to the existing legal framework and
providing feedback to both the legislative process of the proposed Regulation as well as policy and
standardisation activities. It will also define a transition plan for the organisational structure needed
after the expiration of the Task Force's mandate in order to ensure the smooth continuation of the
activities related to the follow up of the future eIDAS legal framework.
The e-SENS electronic identification (eID) process, as supporting technology for the e-SENS Patient
Summary, and ePrescription/ eDispensation use case, is based on the generic inter action pattern
“Patient Identification and Authentication”:
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 40
HP at PoC
(Country-B)
(1) hand over( identity traits )
(2) request identifier( identity traits )
(3) provide identifier( identifier, ... )
(1b / 4) verify authenticity
country-B-dataconsumer/producer
patient
country-A
Patient Management
Figure 11: "Patient Identification and Authentication" interaction pattern
ov
al
The patient is identified by electronic means against an eID Provider (STORK/ FutureID) returning a
unique eID for the patient itself. The healthcare professional's software reuses this identifier to
either:
obtain the sectorial eHealth patient identifier by performing the XCPD findIdentityByTraits
transaction

or immediately applies the obtained eID directly for the medical data request if the obtained
patient identifier already qualifies as a sectorial eHealth patient identifier
ap
pr

Pe
nd
in
g
EC
Once the patient is univocally identified (traditional XCPD workflow) or authenticated (e-SENS eID
workflow) in the remote country, healthcare professional obtains a TRC assertion from the NCP-B.
Using the IdA and the TRC assertion, any epSOS transaction is performed.
Figure 12: Generic e-SENS eID Flow of Events
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 41
2.5.3.5.1.
Preconditions
Medical data MUST only be disclosed or shared by means of epSOS after the patient was identified
and authenticated with sufficient accuracy (with respect to country-A demands). Each country-Bdata-consumer as the intended recipient of medical data MUST identify and authenticate the patient
with sufficient accuracy. A country-B-data-producer MUST identify and authenticate the patient with
sufficient accuracy before releasing medical information about that patient to a country-A-dataconsumer. On successful identification country-A MUST issue a unique patient identifier that can be
used for further transactions on the patient’s medical data. Country-A MAY restrict the usability of
this identifier to a certain time span or to a certain requestor.
Implementations of this binding MUST consider the epSOS standard security safeguards in order to
preserve basic protection for data confidentiality, data integrity and patient privacy:
All messages MUST make use of the Web Service Security Standard and the WS Addressing
Standard as defined in [EED-Messaging].

Each request message MUST contain a claim on the identity of the requestor as defined in
[EED-B ACS SAML] and [EED-Messaging].

The service provider MUST verify the integrity and authenticity of this claim for each
incoming request.

Before disclosing patient identity data the service provider MUST verify the existence of a
valid consent and assess all applicable security policies.
2.5.3.5.2.
EC
ap
pr
ov
al

Existing Technology and Processes
Pe
nd
in
g
Within epSOS, the eID aspects are processed prior to any medical data request or exchange through
dedicated services of epSOS itself, country-B, and country-A as illustrated through Figure 3.
Therefore, any business process is initiated by locally authenticating the healthcare professional in
country-B through the available health IT means at this particular PoC. This authentication either
directly yields or is transposed into a transferable claim that is technically represented by a SAMLv2
assertion. However, following the notions of Figure 3, this particular assertion may only carry
attributes from its original domain, the subject domain and lacks epSOS or cross-border specific
context as well as a univocal link to a treatment context binding one healthcare professional to a
particular patient. Consequently, the context domain of country-B may enrich the local assertion
with any additional attributes required, ultimately yielding an epSOS Identity Assertion (epSOS IdA).
The healthcare professional is now able to initiate the patient identification process. The patient
identification operation itself is currently merely populated with demographic traits such as a health
insurance identifier or a combination of name, birth date, and address. Both, the identity traits as
well the healthcare professional’s IdA are relayed to country-A enabling it to take comprehensive
access control decisions based on the claims and evidences received from country-B. Country-A is
now following the next sequence to conclude the patient identification:
1.
Validate the identity and authenticity of the service consumer
2.
Verify that the requesting healthcare professional is authorized to query for patient IDs
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 42
3.
Extract the patient identity traits from the message body
4.
Search for patients that match the provided ID attributes
5.
Depending on the number of matches:
If multiple patients match: request for more identity traits or provide a list of
candidates (depending on national security policy). If a list of matching candidates is
provided it MUST only include patients who gave consent to epSOS with a disclaimer
on this specific point to inform the healthcare professional.

If a single patient matches and this patient has given consent to epSOS: select ID to
be used for subsequent requests

Any other case: throw respective fault
al

Write an audit trail entry for the request and its result
7.
Apply epSOS protection means to the response message and send it to the requestor
ov
6.
Pe
nd
in
g
EC
ap
pr
In the success case, country-A is reporting the shared identifier of the patient that may be used to
query medical information for that subject. However, before any data disclosure may be authorised
by country-A, another transferable authorisation claim encoded in SAMLv2 needs to be obtained: the
Treatment Relationship Confirmation Assertion (TRC(A)). The TRC certifies the existence of a current
treatment relationship between a healthcare professional and a patient as well as the context of this
particular treatment by linking the healthcare professional IdA with the previously retrieved patient
identifier and the specific purpose of use of the current treatment episode. A comprehensive
overview of the interplay of all eID, authentication, and authorisation provisions within epSOS is
provided through Figure 13.
Figure 13: epSOS Assignment of Concerns in eID and AuthZ
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 43
The patient identification service is always implemented at NCP-A and requested by NCP-B. The
service
contract
consists
of
two
messages:
FindIdentityByTraitsRequest
and
FindIdentityByTraitsResponse.
NCP-A
NCP-B
findIdentityByTraitsRequest
ov
al
findIdentityByTraitsResponse
Figure 14: Patient identification service interaction
EC
ap
pr
In order to identify a patient NCP-B MUST firstly send a findIdentityByTraitsRequest message to NCPA. This message carries identity traits of the patient (e.g. local healthcare id) and optional credentials
for verifying the authenticity of the patient. NCP-A MUST respond to a findIdentityByTraitsRequest
message by returning a findIdentityByTraitsResponse message to the requestor. If the patient was
successfully identified and authenticated, this message carries the shared patient identifier that
MUST be used by NCP-B and NCP-A for any further message exchange related to that patient.
findIdentityByTraits()
Description
Obtain a shared patient identifier
Requestor
Consuming Gateway at NCP-B (service consumer at the country of care)
Input Message
FindIdentityByTraitsRequest
Pe
nd
in
g
Operation
(1) List of patient identity traits as provided by the patient to the healthcare professional at the PoC in
country B
Output Message in FindIdentityByTraitsResponse
successful Case
(1) Unique identifier of the patient that has to be used for all subsequent calls for this patient’s medical
data.
(2) Optional: further patient identity traits that allow the healthcare professional to verify the result of
this operation.
If no unique match is found, the service provider MAY respond with a list of candidates. For each
candidate body elements (1) and (2) MUST be provided.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 44
Precondition of
success scenario
The following preconditions MUST be met for successful processing:
1. The patient has given a consent that authorizes NCP-A to disclose his identity
2. The patient is able to provide identity traits that are sufficient for a unique identification
3. NCP-B has discovered the service endpoint at NCP-A and is able to connect to that endpoint
4. A trust relationship and a secure communication channel have been established between NCP-B
and NCP-A
5. Healthcare professional -B was successfully authenticated in country-B
6. NCP-A is able to verify the authenticity of the requestor and the legitimacy of the request
Actions of the epSOS Patient Identification and Authentication Service provider:
1. Validate the identity and authenticity of the service consumer
al
Main success
scenario
ov
2. Verify that the requesting healthcare professional is authorized to query for patient IDs
3. Extract the patient identity traits from the message body
ap
5. depending on the number of matches:
pr
4. Search for patients that match the provided ID attributes
EC
- If multiple patients match: request for more identity traits or provide a list of candidates (depending
on national security policy). If a list of matching candidates is provided it MUST only include
patients who gave consent to epSOS.
- If single patient matches and this patient has given consent to epSOS: select ID to be used for
subsequent requests
in
g
- Any other case: throw respective fault
Pe
nd
6. Write an audit trail entry for the request and its result
7. Apply epSOS protection means to the response message and send it to the requestor
Fault Conditions
Preconditions for a success scenario are not met
Requesting healthcare professional has insufficient rights to query for a patient’s identity
No matching patient is discovered that gave consent to epSOS
ID traits are insufficient for country A to find a matching patient (e.g. provided search criteria are not
supported)
Patient identification is only performed in conjunction with patient authentication (e.g. as specified for the
epSOS Extended Security Safeguards)
Confirming the query would lead to a privacy violation acc. to country-A legislation.
Table 4: findIdentityByTraits() operation
The original epSOS specification acknowledges the limitations and constraints of the identification
process and its assigned technology and established the anchor for advanced eID interactions. If a
country requires an additional authentication of its citizens when they ask for medical care in
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 45
another country, this country MUST define its own authentication service. The epSOS Identification
Service findIdentityByTraits operation only provides the mechanism for transparently transporting
authentication data alongside with the transactions (piggybacking) between NCPs. This is done by
using two HL7v3 instance identifier within a single LivingSubjectID element; one identifier is used for
identifying the patient while the other one is used for authentication of the patient.
2.5.3.5.3.
Use Case Scenarios: eID via STORK and FutureID
To support the two e-health Use Cases “ePrescription” and “Patient Summary” the reuse (and
extension) of functionality developed within the two European projects FutureID and STORK was
analyzed in detail. Four use cases complete existing epSOS functionalities:
Digitally sign a patient privacy consent acknowledgment document in the country of
treatment

Authenticate patient via national certification authority means in the patient’s country of
affiliation

Retrieve identity attributes locally in order to support a standardized demographics query for
patient identification in the country of treatment

Realize end-to-end security when disclosing medical data through establishing cryptographic
keys based on short transaction numbers
ap
pr
ov
al

EC
SCENARIO 1: Using FutureID’s Local Attribute Retrieval and Mapping (LARM) functionality to
support patient identification
Pe
nd
in
g
In many scenarios where persons are only partially involved in certain activities it might be sufficient
to just IDENTIFY the data subjects properly using their tokens (e.g. eIDs, electronic Health Cards).
Identification in this case means, to read attributes that are electronically stored in unprotected parts
of the token.
Example Scenario 1: A healthcare professional is allowed (a consent was given earlier) to
access the data of Patient A which is registered under the patient’s insurance number
(A1234567890). The insurance number is stored on the electronic health card (EHC) of the
patient and can be read without further requirements (e.g. entering a PIN). Instead of typing
in the number manually using a keyboard the healthcare professional just inserts the EHC
and the identifier is read automatically.
Example Scenario 2: A healthcare professional wants to register the details of a patient (e.g.
given name, surname, date of birth, address) in his patient’s database. Instead of entering all
data manually using a keyboard, the IT-system reads the data automatically and fills in the
required fields. Only missing information must be added manually.
Relevance for “ePrescription” and “Patient Summary” Use Cases
To access the patient’s medical data (e.g. a patient summary or ePrescription) through epSOS the
patient identifier (epSOS patient ID) that is assigned to this data must be known. The identifier can be
retrieved by using the epSOS Patient Identification and Authentication Service. A request based upon
IHE XCPD (cross-community patient discovery) is sent to this service by the client (e.g. the healthcare
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 46
professional’s epSOS portal). The request contains so-called identity traits which can be the given
name, surname, date of birth, gender, address or arbitrary identifiers. Based on the identity traits the
service tries to discover the appropriate patient and the corresponding id and returns that
information back to the client.
At the moment for each country participating in epSOS or any of its follow-up activities different
identity traits are used within the request. Right know these identity traits must be entered into the
local HIT manually using country specific forms. This procedure often is error prone, time-consuming,
and therefore less likely to be accepted by most healthcare professionals. As the imprint of national
eIDs is often used as the source of this manually entered information it is obvious to directly
integrate it with the system.
Computational Perspective
Pe
nd
in
g
EC
ap
pr
ov
al
FutureID’s Local Attribute Retrieval and Mapping Service (LARMS) provides a set of capabilities
through which software components that are running locally can access identity attributes that are
stored on hardware based tokens (e.g. European eIDs or other smartcards) and map them onto a
predefined format (e.g. a SAML-Assertion or JSON Web Token).
Figure 15: Encapsulation and Abstraction of national eID
The service is able to map attributes stored in different formats (e.g. subject-DN of X.509 certificate,
BCD encoded data or a proprietary XML format) and different places (e.g. proprietary EFs) on to a set
of well-defined attribute types in a well-defined format.
Figure 16: Retrieval & Mapping from eID to cross-sector Asserting
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 47
The main tasks of the service include the retrieval of the data from the hardware token (READ),
optionally the decompression of stored data (DECOMPRESS), the parsing of information fields
(PARSE), the mapping of attributes into a normalized form (MAP) and finally the embedding of those
attributes into a predefined container format.
Both, STORK and FutureID are currently defining a set of attributes and making those available for
consumption by either a Service Provider or consumer. This set of attributes contains demographic
information about the data subject as well as technical and organizational artefacts that streamline
the discovery and application of eID. Table 5 lists an exemplary set of attributes and their potential
consumption through e-SENS.
Name
eIdentifier
http://www.stork.gov.eu/1.0/eIdentifier
Given Name
http://www.stork.gov.eu/1.0/givenName
Surname
http://www.stork.gov.eu/1.0/surname
Gender
http://www.stork.gov.eu/1.0/gender
Input value for identity traits provision in
traditional XCPD workflows
Date of
http://www.stork.gov.eu/1.0/dateOfBirth
Input value for identity traits provision in
traditional XCPD workflows
Birth
Nationality
Canonical
ov
pr
ap
EC
g
in
Country of
Input value for identity traits provision in
traditional XCPD workflows
Input value for identity traits provision in
traditional XCPD workflows
http://www.stork.gov.eu/1.0/countryCodeOfBirth
Input value for identity traits provision in
traditional XCPD workflows
http://www.stork.gov.eu/1.0/nationalityCode
Determination value of destination country
and health services legibility
http://www.stork.gov.eu/1.0/canonicalResidenceAddress
Determination value of destination country
http://www.stork.gov.eu/1.0/eMail
Means of contact for direct data subject
communication
http://www.stork.gov.eu/1.0/residencePermit
Determination value of destination country
and health services legibility
Pe
nd
Birth
Use within e-SENS eID
al
Friendly Name
Residence
Address
eMail
Address
Residence
Permit
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 48
Pseudonym
http://www.stork.gov.eu/1.0/pseudonym
Advanced security safeguard for preserving
patient-controlled privacy and protecting
national health identifiers
Fiscal
http://www.stork.gov.eu/1.0/fiscalNumber
Potential unique identity trait for crosssector authentication of data subjects
Health Insurance Id
http://www.futureid.eu/attributes/common/healthInsuranceId
Potential unique patient identifier for
immediate authentication of data subjects
CardType
http://www.futureid.eu/attributes/common/cardType
Decision value for the Service Meta-Data
Locator to retrieve a list of capabilities and
compatibility for the particular eID token
carrier as well as LoA anchor
Display Name
de-egk
German Electronic Health Card
(Elektronische Gesundheitskarte [eGK])
de-npa
German Citizen Card
ap
pr
Code
ov
al
Number
(neuer Personalausweis [nPA])
Portuguese Citizen Card
(Cartão de Cidadão [CC])
it-cns
Italian National Service Card
(Carta Nazionale dei Servizi [CNS])
Italian Electronic Identity Card
(Carta d’Identitá Elettronica [CIE])
Pe
nd
it-cie
in
g
EC
pt-cc
es-dnie
Spanish National ID Card
(Documento Nacional de Identidad
Electrónico [DNIe])
be-eid
Belgian eID
[…]
Continues with listing all applicable
European eID carriers
CardIssuerCountry
http://www.futureid.eu/attributes/common/cardIssuerCountry
Determination value of destination country
and health services legibility
CardId
http://www.futureid.eu/attributes/common/cardId
Non-repudiation and traceability
Table 5: STORK Identity Attributes Excerpt
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 49
SCENARIO 2: Using FutureID’s Signature functionality to authorize the retrieval of medical
information by involving the patient
To digitally sign documents using a national eID while being abroad (without having access to your
own IT infrastructure) is still a big issue. Some steps to solve these problems have been taken by
STORK. Nevertheless, FutureID currently develops a client component (FutureID client) that can be
easily extended to support electronic signatures with most European eIDs.
Relevance for “ePrescription” and “Patient Summary” Use Cases
ap
pr
ov
al
epSOS integrates a (security) mechanism that is called TRC(A). It is used to vouch for an existing
treatment relationship between a specific healthcare professional and a patient. At the moment this
assertion is digitally signed by an authority within country B. The patient or any of his or her
credentials are currently not involved in the process. Technically and from a patients’ rights
perspective, this leads into an unsatisfactory situation in which the claim and the accompanying
evidence is issued by the very same entity. If the patients’ signature material can be used to
authenticate the TRC, the legal stability (transition from blank consent to patient-authenticated and
–authorized transactions) as well as the technical enforceability of the patients consent, transactional
assertions, and trust relationships is significantly strengthened. Ultimately, the proper and
complimentary interlocking of specifically the patient consent and a patient-controlled TRC lay the
foundation to anchor to empower the patient as encouraged by the Patient Rights Directive.
Computational Dimension
Pe
nd
in
g
EC
The Signature Service of the FutureID client provides a set of capabilities that enable its user to sign
electronic documents or other electronic data in different formats using predefined signature
policies.
Figure 17: Capabilities of FutureID signature service
A special signature policy can be introduced to support the proper rendering of TRC-Assertion
content into a human understandable format and to correctly sign the underlying SAML Assertion.
SCENARIO 3: Supporting Patient Authentication by using a mixture of STORK and FutureID
functionalities
The Digital Agenda for Europe states several key initiatives for information and communication
technologies (ICT) where forces should be combined. One objective of the European Commission is
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 50
to “[…] equip Europeans with secure online access to their medical health data by 2015 […]7”. The
epSOS project picked up that mission so that the epSOS patient access use case has been adopted.
The epSOS Patient Access (PAC) Service enables patients to seize their rights with regard to
processing their medical data:

Displaying of medical data stored within patient data source

Suspension/ release/ deletion of medical data stored within patient data source

Access to audit logs

Revocation of a given consent to use a specific epSOS application (e.g., Patient Summary)
al
Secure online access involves a proper authentication of the patient, e.g. by using his or her eID.
Within STORK an infrastructure that supports cross border authentication was already developed and
(in parts) established. Therefor the STORK functionality should be reused wherever possible.
ap
pr
ov
A first proof of concept already was developed within STORK 2.0 and used the Austrian Mobile ID to
authenticate against the epSOS patient access portal. Nevertheless the support of smartcard-based
eIDs (especially when being abroad) is still a big issue as no common middleware components do
exist. This will change in the near future with the completion of the FutureID Client (FC)
development. The FC and additional Future ID components will support a smartcard based
authentication process using STORK as the authentication backend infrastructure.
EC
Computational Dimension
Pe
nd
in
g
FutureID’s Patient Access Authentication Service (PAAS) provides a set of capabilities to authenticate
patients using different authentication back end (e.g. STORK).
Figure 18: Capabilities of FutureID authentication service
FutureID already defines with the AIS declaration language a method to describe the authentication
requirements (necessary attributes, authMethod etc.) of a service. To support the authentication
against the Patient Access Portal this language must be used to define the requirements that are
specific to epSOS.
7
European Commission, Digital Agenda for Europe: key initiatives [HTML, DOC, PDF]. MEMO/10/200. 2010-0519. [cited 03 March 2015]. Available from Internet: http://europa.eu/rapid/press-release_MEMO-10200_en.htm?locale=en
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 51
2.5.3.5.4.
Building Block Implementation and Integration
The extension of the eID services through FutureID, however, required the integration and
deployment of two FutureID architectural components at the country-B level to enable and
accommodate advanced functionality directly within the user agent and portal back ends, as
illustrated in Figure 19.
Abstraction Layer
National
Infrastructure
Country B
country B
pr
(epSOS consumer domain)
NCP-B
Infrastructure
ov
Point of Care
National
Contact
Point
al
Portal
FutureID AIS
Trusted
HCPO
Environment
Browser
FutureID
Client
ap
Figure 19: FutureID component deployment within a Trusted Zone of Country-B
in
g
EC
In contrast to deploying the FutureID components directly into a trusted zone, which delimits an area
under the direct supervision of a healthcare professional and benefits from special regulatory
protection, a different deployment scenario has to be taken into account for making protected
health information available to the data subjects itself within their country of affiliation (Patient
Access use case).
Pe
nd
Non HCPO
Environment
National
Infrastructure
Country A
Abstraction Layer
Web
Service
Web
Service
Web
Service
NCP-A
Infrastructure
Web Service
Abstraction Layer
National
Contact
Point
Citizen
FutureID
Client
Browser
FutureID AIS
Patien Access Portal
epSOS
Pati ent Data
Source
HCPO
Environment
country A
(epSOS provider domain)
Figure 20: FutureID component deployment with public access in Country-A
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 52
2.5.3.5.5.
Sequencing of Healthcare Processes and Profiles
The operation of the eID BB in conjunction with the capabilities from STORK or FutureID regulates
the initiation and sequencing of the involved healthcare standards, profiles, and processes. The
fundamental sequence for substituting the existing epSOS eID means with e-SENS technology is:

obtaining and processing the patient’s eID token carrier

localizing and determining the eID capabilities of that particular carrier

matching all supported eID and Access Control capabilities between country-B and country-A

selecting the most appropriate eID process template (service metadata discovery service):
traditional epSOS XCPD for incompliant or incompatible eID technology (exclusive
country-A processing with country-B only communicating semantic-free identity
traits)
o
eID-assisted epSOS XCPD with automatic transfer of the eID token carriers identity
traits and assigning authority into the XCPD request message and no human
interaction
o
provision of authenticated SAML attributes encoding the identity traits required for
XCPD and to populate the TRC-A
o
provision of the national patient identifier as authenticated SAML attribute through
the eID service to populate the TRC-A (effectively rendering XCPD redundant)
o
creation and issuance of the TRC-A by the external eID service with the assertions
signature being applied by the patient’s eID carrier or a trusted service from countryA (effectively rendering XCPD redundant)

Pe
nd
in
g
EC
ap
pr
ov
al
o
negotiating and selecting the most appropriate access control template:
o
enable re-sequencing of healthcare transactions (such as omitting XCPD before XCA)
o
traditional epSOS under an indirect brokered trust relationship with communication
channel encryption through TLS and audience restriction by IPSec
o
electronically signing the data request and/or TRC-A using the means of the eID
carrier
o
individually encrypting the data or transport channel using a key agreement
mechanism that is based or derived from the eID carrier (such as PAKA)

activating the appropriate access control system policy to accommodate the selected eID
process template for the particular transaction at NCP-B and NCP-A

re-sequencing of the healthcare transactions:
o
make XCPD optional in accordance with selected eID process template
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 53
o

populate XCA request(-s) in country-B
reset
Pe
nd
in
g
EC
ap
pr
ov
al
The flexibility towards sequencing enables three basic patterns that can be freely instantiated by the
piloting nations:
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 54
va
l
ap
pr
o
EC
Pe
nd
in
g
Figure 21: Traditional XCPD using Identity Traits
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 55
va
l
ap
pr
o
EC
g
in
nd
Pe
Figure 22: eID and XCPD combined workflow with no Re-Sequencing
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 56
eHealth
Facade B
Metadata
Locator Srv.
STORK/
FutureID
AuthN HP (IdA)
Identify Patient through eID token carier & STORK w/ HP IdA
EC
Capability List
eHealth
Facade A
g
Ida + TRC + opt.
Supporting
Token Packaging
OPTIONS:
issue SAML Atrribute Statement containing citizen or patient ID
issue TRC assertion Attribute Statements for PatID and HP ID
issue Offline/Guarantor-style token to be relayed to A instead of ID
issue and register one-time pseudonym for data access
issue SAML AuthzDecisionStatement Decision
etc.
ap
pr
o
AuthN HP







va
l
HIT@PoC
in
request medical data (XCA/XCF) with HP IdA & 1+ options from eID
nd
return medical data
Pe
Figure 23: eID-triggered Re-Sequencing without XPCD
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 57
NI-A
Backoffice
2.5.4.
Use of established infrastructure at EU and MS level
e-SENS (and the CEF) aims to adopt mature available technologies. This section introduces materials
developed by other LSPs and other initiatives that may be re-used.
2.5.4.1. From prior LSPs
Re-Use of Results
ov
Initiative/ LSP/ Support Act
al
The underlying technology of this use case heavily relies on central services for publishing and
processing cross-border configuration information. Those services are currently unavailable due to
the hand-over of responsibility from epSOS towards its managing successor EXPAND. This process
has not yet been concluded and the appropriate information will be completed within the detailed
design of the pilot.

the results regarding proper eID in the healthcare
domain are processed and addressed within the eID BB
epSOS ESS

the identified need for better identification,
authentication as well as authorization of/by the patient
toward the disclosure of protected health information is
a fundamental driver for this pilot use case
ap
EC
the technology established by epSOS ESS is partially
integrated into the respective e-SENS BB and where not
fully backwards compatible to the Extended Security
Safeguards
EXPAND
Pe
nd
eHN
in
g

pr
eHealth Government Initiative
eHGI

the legal framework agreements that needs to be signed
in order to make it possible to run pilots with operational
systems and use real data

EXPAND is the guardian of several epSOS assets as well as
assets from other European project that have ended. In
that scope, the EXPAND Thematic Network will provide
governance and support whenever an in progress project
aims to fulfil its goals by building on top of those assets.

EXPAND’s main goal is to handover to CEF a set of
mature eHealth assets that could be used as baseline for
the CEF eHealth DSI.

EXPAND can work also as a steering committee for
eHealth Use Case Pilots (like Patient Summary or
ePrescription) assuring the correct alignment with epSOS
requirements and recommendations, as well as the
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 58
foreseen directives for the CEF eHealth DSI.

GINI
the results regarding the establishment of patient-centric
and patient-controlled data disclosure have been
addressed within the pilot use case
Table 6: Potential re-use of established infrastructure from prior LSPs
2.5.4.2. Other Initiatives
Initiative/ LSP/ Support Act
Re-Use of Results

the updated regulatory provisions are incorporated into
both, the fundamental building blocks as well as the
pilots design
IHE International

the updated integration profile specifications will be fully
incorporated into the detailed design of this pilot
OpenNCP

During epSOS at least two (2) proofs of concept have
been implemented: the FETNCP & the OpenNCP. All the
countries planning to pilot e-SENS adopted, in the second
part of epSOS, the OpenNCP.

this pilot considers the OpenNCP as the foundation for
the pilots implementation and operation
ov
pr
ap
EC
this pilot encourages a deep integration of innovative eSENS building blocks as supporting technology of the
OpenNCP
Pe
nd
in
g

al
eIDAS

this pilot commits to driving the evolution of the
OpenNCP regarding maturity, applicability, and
innovation

no constraints are put in any other NCP implementation
Table 7: Other potential re-use of established infrastructure
2.6.
MS relevance
Greece, Italy, Luxembourg, Portugal and Spain have already expressed their intention to pilot.
In order to try to simplify and prioritize the issues exposed, MSs were asked to assess/ validate the
relevance of the importance of the resolution of each of the problems identified in Section 2.5.3 to
the eHealth domain. Table 8 depicts the list of the epSOS problems identified, together with the
corresponding, proposed e-SENS BBs.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 59
Architects
6.3
6.1
6.3
6.3
6.1
6.1
Providers
STORK
2.0
FutureID
?
Developmen
t OpenNCP
IHE-DSG
Develop
ment
needed
Not yet
mature,
developed by
e-SENS
Develop
ment
(Estonia)
OASIS BDXR
OpenPEPOL
eID
Nonrepudiation
eSignatur
e
Trust
Establishment
eInteracti
on
Configuration
Services
√
?
?
?
BB
PROBLEM
Missing evidence
Patient Electronic
Identification
Central
Configuration
Services
?√
?
√
ov
√
End-2-End Security
Patient access to
audit trail
√
√
ap
√
Security Relaxations
√
√
pr
√
Not signed artefacts
al
?
√
√
Table 8: BBs by problem for the eP/PS Use Case
Greece
Sweden
Italy
Luxembourg
Portugal
Spain
Missing evidence
*
*
*
*
*
*
Patient Electronic Identification
***
***
***
***
***
***
Central Configuration Services
*
**
*
*
*
**
End-2-End Security
***
***
N.A.
**
N.A.
N.A.
Patient access to audit trail
**
*
***
***
***
***
Not signed artefacts
*
*
***
*
***
*
Security Relaxations
**
*
*
**
**
*
Pe
nd
PROBLEM
in
g
EC
Subsequently, validation of the relevance of each of the proposed BBs to the eHealth domain for
UC5.2.1 was prepared by involved MSs based on September 12th, 2014 presentation to the WP5.2
plenary meeting. Validation of BB relevance has been provided by Greece, Sweden, Italy,
Luxembourg, Portugal and Spain as depicted on Table 9.
Table 9: Relevance of the problem to the eHealth domain as anticipated by participating MS
The column under the name of each country at Table 9 indicates the relevance of the problem to the
eHealth domain. The number of stars (*) indicates the level of importance of a problem (*** are
used for the highest level of importance, while ** and * are used for lower and lowest level of
importance respectively – *(*) stands for one and a half star).
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 60
According to Greece: (a) End-2-End security is important, to be differentiated from end-to-end
encryption (which is only one of the ways that End-2-End security be achieved and has significant
effects on the overall transport architecture) not applicable, (b) Patient Access to audit trail is
expected to become increasingly important, and (c) Security relaxations expected to become
increasingly important.
According to Spain: (a) eID and the missing evidence to have an eID valid for eHealth domain is very
interesting (maybe the most interesting point) but, in the scope of e-SENS it seems difficult to be able
to add a BB because STORK use cases needs lots of work to serve to exchange of information
purpose, (b) regarding End-2-End security it is not considered that is practice way to walk in or solve
the security problems, it is not possible to implement all the services in each point of care, and (c)
Patient access to audit trail is considered of main interest with eID.
al
Although patient access is very important, however Sweden will most likely achieve this functionality
in their national infrastructure.
ap
pr
ov
Regarding the issue about whether End-2-End security refers to End-2-End encryption only or not, it
has been clarified that End-2-End security is linked to several building blocks: non-repudiation, trust
establishment, eInteraction, configuration services and possible eSignature. For each MS the national
situation must be on the table before reaching any conclusions.
The proposal for MS priorities and piloting scope implications agreed during the October 17 th, 2014
net-meeting is as follows:
Patient identification is considered to be of highest priority, and therefore the e-SENS BB
remains in scope.

Patient access to audit trail is of considered to be of high priority, and therefore the e-SENS
BB for non-repudiation remains in scope (will also solve the problem of missing evidence
even though that was not highly prioritized)

Central Configuration services although not very highly prioritized, are considered to be
background infrastructure and a priority when looking at infrastructure redundancy with
view to CEF adoption. Therefore it is considered to remain in scope.

Not signed artefacts are considered to be of mixed prioritization. It is suggested that it
remains out of scope from the initial piloting plans, since it requires use case extension and
has an IHE dependency.

End-2-end security and security relaxation is considered to be of mixed-to-low prioritization.
It is suggested to remain out of scope for now.
Pe
nd
in
g
EC

2.7.
Pilot Planning: Phases, Activities, Milestones,
Dependencies
2.7.1.
Detailed design of pilot
The UC5.2.1 Patient Summary and ePrescription use cases will start coming to life at the end of
Q2/2015, one year after the epSOS Pilots shut down (Jun 2014).
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 61
For that reason, there are a lot of concerns and expectations that MUST be addressed in order to
make sure MSs, the e-SENS project, the EC and CEF are fully aware on what is expected from this
pilot to achieve.
By that reason, the detailed pilot plan described in the next points, will target phases, activities and
major milestones to be achieved, as well as proposes a Work/Activities Breakdown Structure that
should be followed in order to assure legal, organizational, semantic and technical liability and
interoperability.
Even though MOST of the MS piloting in e-SENS have already piloted PS and eP services during
epSOS, the process described assumes that:
The proposed plan SHOULD be agnostic about previous experiences in piloting these services, in
order to:
Allow new MSs to come on board, passing by the complete process;

Gather evidences from experienced MSs (the ones that already piloted on epSOS) regarding
the guidelines, requirements and recommendations established on epSOS for Piloting
Nations.
pr
ov
al

ap
Based on that premise, the e-SENS eHealth Patient Summary and ePrescription pilots, besides
reusing the use case baseline specifications, will also reuse the following methodologies and
instruments:
EC
epSOS D3.8.28 Final National Pilot Set Up and Deployment Guide
Annex I: Security
o
Annex II: Sequential Implementation Guidelines;
o
Annex V: Visualisation of the Sequential Implementation Guidelines
o
Annex VI: Requirements and Recommendations – checklist
in
g
o
Pe
nd

Each of the previously pointed instruments and baseline procedures may be tailored or improved
whenever e-SENS project believes that:

The provided material is not good enough and more instructions are needed;

The e-SENS context, time frame and state of the art differ from the ones that were
established during the epSOS project.
Instead of going deep in details on each document, the e-SENS pilot plan will provide a structural
flow for pilot deployment and point out to the epSOS instruments that may be used in each step of
the way.
8
epSOS. D3.8.2, Final National Pilot Set Up and Deployment Guide [PDF]. Version 1.1. 2010-09-17. [cited 03
March
2015].
Available
from
Internet:
http://www.epsos.eu/uploads/tx_epsosfileshare/D3.8.2_National_Pilot_Setup_and_Deployment_Guide_01.pdf
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 62
al
ov
pr
ap
EC
g
in
Pe
nd
Figure 24: e-SENS WP5.2 eP/PS Summary Pilot Plan
FLOW STEP
DESCRIPTION
OBSERVATIONS
Understand e-SENS
Pilot Scope and Plan
Get in touch with the rationale
behind the e-SENS WP5.2 eHealth
pilot Plan for eHealth, namely
concerning; structure, timings, and
activities; and confirm MS ability to
commit to the plan proposed. The
plan MUST clearly communicate the
expected outcomes so that all
stakeholders may manage
This is the alignment step for all the
stakeholders: e-SENS project, EXPAND
project, MSs, EC, CEF.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 63
expectations from the beginning.
Understand the Patient Summary
and ePrescription (eDispensation)
use cases, namely the complete
workflows and the implications
introduced by the adoption of the eSENS Building Blocks (having as
baseline the epSOS specifications)
This is where the gap analysis between
what epSOS pilot was and what the
e-SENS pilot will be, meets the needed
technical specifications that will guide
implementation tasks.
Evaluate whether
OpenNCP and
Central Services can
be reused
Deep analyse and describe the
impact of the incorporation of each
e-SENS proposed Building Block or
BB feature is such a way that we can
move from architectural perspective
to implementation level with clear
specifications for MS or
Communities to implement. With
this input in hand an unbiased
analysis can be made in order to
understand the level of reusability
possible with epSOS NCP reference
implementation and central services
This step assures if the epSOS assets
(OpenNCP, Central Services) are fit for
the purpose of e-SENS. If not, a
challenging and complex development
path MUST be designed (with detail
beyond the one presented in this
document)
MS instantiate
OpenNCP
MSs instantiate the National Contact
Point based on the OpenNCP
reference implementation, provided
by epSOS and the OpenNCP
Community (currently steered by
EXPAND)
PATH A: Reuse OpenNCP and epSOS
Central Services
MS review National
Connector
Since the National Connector is the
only component where
responsibility lies on the MS, it is
very important that a Quality Review
of this component (features and
business logic) to be reviewed
according to the updated specs that
may arise from e-SENS
PATH A: Reuse OpenNCP and epSOS
Central Services
OpenNCP
Community enhance
reference
implementation,
according to e-SENS
Req. and Spec.
Work closely with the OpenNCP
Community (currently steered by
EXPAND) providing the means (e.g.
specification, funds) for implement,
refactor, integrate or improve any
Building Block with impact at the
PATH A: Reuse OpenNCP and epSOS
Central Services
Pe
nd
in
g
EC
ap
pr
ov
al
Study epSOS Req.
and Spec.,
and update them (in
EXPAND) accordingly
to e-SENS
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 64
NCP level.
In order to assure the epSOS
architecture all needed conditions to
work, the first step is find the
needed conditions to restart the
current central services. This step
will allow MS to technically restart
exchange of data by allowing the
automatic synchronization of
infrastructural communications
settings.
PATH A: Reuse OpenNCP and epSOS
Central Services
Refactor epSOS CS
Architecture
Evolve the epSOS Central Services
rationale (architecture and services)
by adopting e-SENS Building Blocks
or BB features. This step will have
impact also at NCP level where
refactoring will need to be made in
order to allow the improved
articulation model between NCPs.
PATH A: Reuse OpenNCP and epSOS
Central Services
MS implement NCP
If by some chance, the epSOS assets
(OpenNCP reference
Implementation) are evaluated as
not fitting to the purpose of e-SENS,
detailed specifications (e.g. like the
ones provided by epSOS) must be
provided to MS so that they
implement their NCP.
PATH B: Build e-SENS specific solution
If by some reason, the epSOS assets
(Central Services, MVC) are
evaluated as not fitting to the
purpose of e-SENS, detailed
specifications MUST be provided for
WP5.2 team to develop new central
services or tender the development
process.
PATH B: Build e-SENS specific solution
The testing step aims at gathering
strong evidenced of compliance with
specifications and profiles (if
possible, collected face to face by
independent entity) from the several
MSs piloting in e-SENS.
If possible base on a IHE Connectathon
(foreseen for April 2015)
At least one face-to-face event MUST
be accomplished. Remotely test stages
should also be defined in order to
allow the testing after each major
Pe
nd
in
g
EC
ap
pr
ov
al
Restart epSOS
Central Services
e-SENS implement CS
Test NCP
 This path will take considerably
longer time than PATH A. At this
point, is very difficult to say if it
would be possible to fit within eSENS time window.
 This path will take considerably
longer time than PATH A. Besides
time, this path puts more financial
pressure over this task.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 65
release (NCP or Central Services)
The Audit step aims at gathering,
from each MS willing to pilot, a
readiness report on the several
dimensions of the pilot (technical,
semantic, security, organizational
and legal – if applicable)
The aim is not to obtain a report
elaborated by and independent entity,
but to obtain a detailed report from
each MS on the activities performed
towards the Piloting Requirements and
Recommendations.
Start Piloting
This step identifies the moment
where 2 (two) or more MS reach a
readiness level where the minimal
conditions have been achieved for
exchanging clinical data.
The current plan proposes an agile
way to “Start Piloting” namely by
suggesting that pilots may start
before all the e-SENS Building Blocks
of BB feature are in place.
The proposed agile way, points to a
plan where MS could re-start the
epSOS PPT environments without
any changes to the epSOS
implementation. From then on, any
improvement could be built on top
of that working infrastructure and
services.
The discussion on exchanging test data
(Pre-Pilot Testing environment) or real
patient data (Operation environment)
is a subject that is under deep
consideration. For the time being, the
current plan assumes that every step
should be done without compromising
the possibility of real patient data to be
exchanged in e-SENS pilots if all
conditions for that to happen are
established.
in
g
EC
ap
pr
ov
al
Audit NCP
Pe
nd
Table 10: e-SENS 5.2.1 Pilot Plan for eP/PS
The steps described in Table 10 presents a simplified flow of activities that need to be performed
combining efforts from Domain level team and MS local teams. A more granular list of activities to be
performed and orchestrated at Domain level, with close cooperation with MS, can be found at Annex
I: Pilot Plan. For a more granular list of activities to be performed by MS, please check the following
instruments:

Annex II: Requirements and Recommendations – checklist

Annex III: Sequential Implementation Guidelines

Annex IV: eP/PS PN Pilot Readiness, Requirements, and Recommendations Sheet
Lessons learnt from previous projects reinforce the importance of continuous planning. The plan
ahead is ambitious and has strong dependencies from Building Blocks implementation roadmap and
roll out, OpenNCP Community to congregate the means necessary to enhance the OpenNCP, MS
having the capacity for adopting new releases and deploy them tightly connected with the national
Infrastructure.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 66
For that purpose, the plan presented together with this document MUST be considered as a living
document that MUST be monitored and adjusted whenever circumstances demand it.
The next topic – Technical Implementation – will provide a better insight on the technical aspects
involved in the presented Pilot Plan, so that dependencies and risks may be mitigated without pinch
the e-SENS eHealth Domain Pilot.
2.7.2.
Technical Implementation
There is a strong dependency on outcomes of WP6 BBs, and how fast they can be incorporated in the
proposed solution. It involves integration of the selected BBs with the epSOS and the MS
infrastructure.
al
In order to better understand the technical implementation complexity, a first approach may be to
correctly understand the eHealth Domain Pilot Plan for Patient Summary and ePrescription.
pr
Phase 1: Baselining (time window: Dec-2014 to Jan-2015: 9 weeks)
Purpose: Provide clear picture of the Pilot Plan in order to assure the unbiased
comprehension by all involved, the effort it demands from each and single
stakeholder, understand the changes and their impact on assets, as well as to
understand the dependencies and risks;
o
Outcome: Agreement between all Stakeholders (e-SENS project, e-SENS Clusters 6.x,
EXPAND project, MSs, EC and CEF) in providing all the needed means (e.g. people
time, funds for subcontracting, technical infrastructure) foreseen in the Pilot Plan, in
order to provide the best chances possible for the Pilot to succeed.
EC
ap
o

Phase 2: Restart Piloting (time window: Feb-2015 to Jun-2015: 18 weeks)
Pe
nd

in
g

ov
The pilot plan is organized in 4 (four) phases, as presented in Table 11. Each phase has a purpose and
a clear defined outcome:
o
Purpose: Re-establish the baseline conditions (e.g. Central Services) for MS to Pilot
the PS and eP (PPT environment) enhancing the NCP reference implementation
according to the e-SENS BB “Non-Repudiation”
o
Outcome: Restart PS and eP pilots on step ahead from the epSOS pilots by adding a
non-Repudiation mechanism to the NCP transactions aligning OpenNCP with the how
and where evidences for traceability and reconstruction for transactions that process
protected health information are captured and documented.
Phase 3: Central Services refactoring (time window: Jun-2015 to Jul-2015: 17 weeks)
o
Purpose: Refactor the Central Services Architecture and operation paradigm (namely
the Configuration Services – not the Terminology), by providing an e-SENS approach
based on „Trust Services SAT“(upcoming ABBs) combined with „Configuration
Services“.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 67
o
Phase 4: Patient eID (time window: Aug-2015 to Dec-2015: 16 weeks)
o
Purpose: include the possibility of Patient identification based on Electronic tokens.
Improving the liability and the user friendliness of the current process that consists
on manually entering the Patient Identification (may vary from a 12 to 25 digit
number or several fields of information).
o
Outcome: Release for MS adoption, a new version of the NCP reference
implementation that combines two methods of patient identification: a) manual (as
it was on epSOS); b) Electronic according to the e-SENS eID BB;
al

Outcome: Deploy a new architecture and operation paradigm for configuration
services based on specifications for cross-border and cross-sector trust
establishment and certificate layouts according to the eIDAS regulation.
IMPACTED ASSETS
DEPENDENCIES AND RISKS
Phase 1: Baselining
 e-SENS D5.2.3 PS and
eP Pilot Plan
 e-SENS project agree and commit needed
effort on the Pilot Plan
pr
ap
 e-SENS 6.X Clusters E-SENS project agree
and commit needed effort to roll out BB
in
g
EC
(time window: Dec2014 to Jan-2015: 9
weeks)
ov
Phase
 Central Services (as
they were on epSOS)
(time window: Feb2015 to Jun-2015: 18
weeks)
 e-SENS BB: NonRepudiation
Pe
nd
Phase 2: Restart
Piloting
 OpenNCP (and
Community)
 MSs agree and commit needed effort on
the Pilot Plan
 EC and CEF agree and commit needed
effort on the Pilot Plan
 e-SENS 6.1 “Non-Repudiation” BB roll out
 Central Services Up and Running
 OpenNCP Community to integrate the
“Non-Repudiation” BB
 MS adopt and deploy the NCP
 PS and eP Pilots
Phase 3: Central
Services refactoring
 e-SENS BB: Trust
Establishment
 e-SENS 6.3 “Trust Establishment” BB roll
out
(time window: Jun-2015
to Jul-2015: 17 weeks)
 e-SENS BB:
Configuration
Services
 e-SENS 6.1 “Configuration Services” BB roll
out
 Central services
(refactored)
 e-SENS WP5.2 Domain
Implement/Instantiate the new
configuration services for eHealth
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 68
 OpenNCP (and
Community)
 OpenNCP Community capacity to integrate
with new Configuration Services
 Perform required testing to allow activation
in PPT
Phase 4: Patient eID
 e-SENS BB: eID
 e-SENS 6.3 “eID” BB roll out
(time window: Aug2015 to Dec-2015: 16
weeks)
 OpenNCP (and
Community)
 OpenNCP Community to integrate the “eID”
BB
 MS
 MS to have the national eID framework up
and running
ov
al
 Perform required testing to allow activation
in PPT
Table 11: eP/PS pilot plan phases
Provide clear picture of the Pilot Plan in order to assure the unbiased comprehension by all
involved, the effort it demands from each and single stakeholder, understand the changes
and their impact on assets, as well as to understand the dependencies and risks;
EC

ap
pr
Facing the technical challenges that lie ahead for the eHealth Pilot on PS and eP to come to life, is
fundamental that the first – and most commonly underestimated – step to be executed in
perfection:
Pe
nd
in
g
The possibility of having a face to face meeting where all the stakeholders go activity by activity and
risk by risk, making them to understand the eHealth Pilot Plan effort by heart, can create the
fundamental conditions for stakeholders to commit the amount of effort needed as well as adjust
expectations according to what is foreseen as possible with this distance ahead.
The next topic will approach the testing and conformance assurance testing, that will work as a
platform for gathering evidences on all the piloting sites guidelines, requirements and
recommendations fulfilment.
2.7.3.
Readiness Testing and Conformance
Tests between participating countries will be required, together with business enablement of
participants. It is proposed that the revised epSOS Testing strategy be applied also to e-SENS eHealth
eP/PS pilots:
- http://www.epsos.eu/uploads/tx_epsosfileshare/D3.C.1-Proof_of_Concept_Testing_Strategy-v1.5.pdf
- http://www.epsos.eu/uploads/tx_epsosfileshare/D3.C.1_Appendix-A-Revised_Requirements_of_epSOS_Testing_Environment-v1.0.pdf
- http://www.epsos.eu/uploads/tx_epsosfileshare/D3.C.1_Appendix-B-Proof_of_Concept_Testing_Strategy_Details-v1.6.pdf
- http://www.epsos.eu/uploads/tx_epsosfileshare/D3.C.2_epSOS_Phase_2_Test_Infrastructure_with_All_Tools_v1.0.pdf
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 69
Additional info can be found in epSOS D3.8.29, D3.9.210 and D3.10.111.
The test strategy defined in epSOS, including all the testing activities performed by the implementers
(e.g. the members of the OpenNCP communities on the components, their integration and the
validation before the release), plus all the tests performed by the PNs (pre-PPT conformance and
workflow testing, and Connectathon Interoperability Testing, before being allowed in PPT
environment; PPT and functional end-2-end testing with the similar National clinical infrastructure,
the interoperability and security cross-border infrastructure, before being allowed in Operation; the
regression tests in Operation before being allowed to open the services to real patients have to be
performed also in e-SENS.
ov
al
The "testing strategy" in epSOS covered Legal, Security, Semantic, Organisational and technical
aspects. Conformance Gates were set for all these dimensions, starting from Level 0 (to allow a
Participating Nation to enter in pre-Projectathon), Level 1, to be allowed to enter in the Pre-PilotTesting environment (where all PNs were connected to exchange virtual patients data, and Level 2,
to be allowed in Operation (which included also regression tests among all the PNs).
Launching and Running
ap
2.7.4.
pr
Pre-conditions for the availability of operational pilots are resources and legal framework.
Pe
nd
in
g
EC
Once the solution has been tested and validated, it can go live, subject to legal requirements and the
pre-conditions set.
9
epSOS. D3.8.2, Final National Pilot Set Up and Deployment Guide [PDF]. Version 1.1. 2010-09-17. [cited 03
March
2015].
Available
from
Internet:
http://www.epsos.eu/uploads/tx_epsosfileshare/D3.8.2_National_Pilot_Setup_and_Deployment_Guide_01.pdf
10
epSOS. D3.9.2, Testing Methodology, Test Plan and Tools [PDF]. Version 1.0, 2010-10-15. [cited 03 March
2015].
Available
from
Internet:
http://www.epsos.eu/uploads/tx_epsosfileshare/D3.9.2_Testing_Methodology_Test_Plan_and_Tools_01.pdf
11
epSOS. D3.10 is a restricted deliverable. Specific request should be sent to obtain it. CIP/PSP EXPAND will
provide a Public revised version.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 70
3. National Pilot Plan of Spain for UC 5.2.1
3.1.
Pilot Scope
3.1.1.
Domain Use Case to be piloted
Spain, within the eHealth domain, aims to pilot the Patient Summary exchange use case following
epSOS specification. That will be the starting point needed to include the e-SENS BBs of nonrepudiation and, if possible, of eID, in order to consolidate and improve the developments and make
them more reusable.
3.1.2.
ov
al
Because of the project time and resources constraints (no legal framework, no Regions-Ministry
contract in place, etc.) the exchange will have to be done with no real information from real patient.
National Motivation and Goals
ap
pr
Spain has a decentralised eHealth system in which the regions are responsible of all health care
matters except for General Organization and Coordination, International Health and Pharmaceutical
Products that are the ones that the Ministry of Health has to take care of. The devolution of Health
affairs to the Regions (Autonomous Communities) started in 1981 and finished in 2001.
EC
Within the Coordination activities there is the need of “....creation of methods to sharing information
and describe technical standardisation...” so there was an early need for interoperability within the
country that makes early developments needed.
Pe
nd
in
g
Several national collaborative initiatives and projects have been launched for eHealth, including both
the Health Ministry and the Regional Health Departments and reaching agreements through a high
level territorial decision body (“Consejo Interterritorial de Salud”). The most important agreements
development has been:

A central eHealth node holds at the Ministry that keeps no clinical information but acts as a
switch point for communications with the regions (NODO CENTRAL)

A central eHealth ID database with one unique eHealth number for each citizens that is the
same during all his or her life and to which regional numbers can be mapped (CÓDIGO SNSTARJETA SANITARIA INDIVIDUAL)

An “Electronic Health Record within the NHS” project in which all activities related with
exchange of clinical information are taken into account (both short and long term). In that
project a National Patient Summary was agreed in 2007.

An ePrescription National project
Through the participation on international projects of clinical exchange of information at different
levels, the Spanish Health Ministry aims:

To share the developments and lessons learnt and to learn from other‘s solution.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 71

To reassure that the national strategies are aligned with what is define in Europe and other
countries and that there is a possibility to construct international exchange from the national
developments and to learn what has to be included in a more complex environment.

To have a better understanding of the European and International Roadmap and to
contribute to it.
Through the participation on e-SENS we aim to improve the clinical exchange that was defined in
epSOS in order to make it a more sustainable and reusable and also to learn where to re-use our
developments in other domains.
Other related Spanish participants are: the eHealth Governance Initiative, the EXPAND project, the
EHN subgroups for CEF and for up-keeping the epSOS services, the Trillium Bridge project.
Business Process Overview
al
3.1.3.
pr
ov
The Spanish pilot will be based on Patient Summary epSOS use case both as Country A (senders) and
B (receivers) as a basis. For that we will create a Patient Summary with fake information that could
be exchange and translated through our central node. To reactivate this we will need the epSOS
central and terminology services in order to:
Be able to send a patient summary that can be translated into another participant country
language plus the original document (country A).

Be able to receive another participant country‘s patient summary translated to Spanish
(country B). A Spanish professional will receive the foreign patient summary.
EC
ap

Pilot participants and Stakeholders
Pe
nd
3.1.4.
in
g
Also, we will implement within the national infrastructure the non-repudiation BB and, if possible the
eID BB and we will test the system making exchange of information with those improvements.
The Ministry of Health, Social Services and Equality:

Information System Department: Health Care Professionals, Electronic Health Records within
NHS project team, semantic experts.

Information Technology Department: in charge of implementation and maintenance of the
central node.
3.1.5.
Pilot Timing
Spain is expected to go live at pre-production with simulated data at Q3/Q4 2015.
3.2.
3.2.1.
Pilot Description
Pilot scenario
The epSOS Open Source developments implemented for epSOS will be activated in the
preproduction environment.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 72
A Spanish Patient Summary will be created with fake information. That document will be included in
the national real infrastructure (with demographic data, ID, certificates, etc.) and could be sent using
the Spanish NCP once the international mask activated. Also, the NCP, through the international
mask based on epSOS specifications, will be able to received foreign patients summaries and
translated through the epSOS MVC.
For that basic part we do need the central services as explained in the group (configuration manager,
MVC-MTCs, etc.).
The non-repudiation e-SENS BB and hopefully the e-SENS eID BB based in STORK 2.0 will be
implemented in the national infrastructure and piloted within the patient summary exchange.
3.2.2.
Use of e-SENS and Domain-Specific Building Blocks
Use of National infrastructure
pr
3.2.3.
ov
al
e-SENS BBs foreseen to be used:
1. Non-repudiation
2. eID based on STORK 2.0 and for patient identification (no professionals)
EC
ap
National infrastructure will be used adding the international part as a mask in the already existing
national stable development. The Ministry central node will add the epSOS Open Source component
and new e-SENS BBs. The Spanish portal used for national exchange is the one used also for
international exchanges.
Pilot Implementation
Implementation Planning
in
3.3.1.
g
3.3.
2015: Q1-Q2 analysis of the BB of non-repudiation and implementation of adaptations
needed on the Open NCP. Creation of a fake patient to exchange the patient summary.

2015: Q3-Q4: actual piloting on preproduction environment.
3.3.2.
Pe
nd

Pilot resources
Spain counts in e-SENS resources to be able to recover central services and to add the e-SENS BB.
Spain has defined a pilot that they can afford with the existing committed resources and some
national ones.
3.3.3.
Pilot risks and overall feasibility
Delays at project level leave a bit of short time for implementation but Spain has finally agreed in
something they hope to be able to pilot for Y3. Piloting depends on the capability to recover the
minimum central services they need for exchange. Resourcing constrains the scope of the pilot but
not the possibility to have a pilot.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 73
4. National Pilot Plan of Greece for UC 5.2.1
4.1.
4.1.1.
Pilot Scope
Domain Use Case to be piloted
The priorities for piloting in e-SENS are determined at the political level within the constraints of the
TA of the project and the readiness of the national pilot partners to support such priorities. Within eSENS, Greece will implement the eID solutions for the ePrescription/ Patient Summary use case
(UC5.2.1).
National Motivation and Goals
Pe
nd
4.1.2.
in
g
EC
ap
pr
ov
al
Greece has piloted, in the framework of epSOS, ePrescription as country of treatment for the
patients (country B). National cross border initiatives are focusing on expanding current services to
services as country of affiliation for ePrescription and also initially as country B for Patient Summary.
In anticipation of the latter, the epSOS national implementation team has already implemented and
tested the epSOS MTC which is necessary for the semantic transformation of the PS. However, the
needed legal and organizational framework for electronic health records, currently in process of
development, will need to be secured before Greece can expand into the eP/PS use case beyond preproduction. It is also understood that the e-SENS eHealth pilot will take place with test data only. ESENS extensions to be piloted need to be able to follow existing current situation in Greece,
especially in the eID domain where end to end security via smart card technology for example is not
supported. As such a STORK based eID approach seems to be more in-line with future developments
at MAREG (Ministry of Administrative Reform and e-Governance of the Hellenic Government,
partner of the e-SENS Greek National Consortium).
The piloting in e-SENS is the next step for Greece to foster European wide cross-border eHealth
services and a logical next step to the epSOS pilot services. Greece is a country with a high influx of
tourists throughout the year. The opportunity to dispense electronic prescriptions and access patient
summaries from other countries in a Greek pharmacy and health care facilities respectively is a great
advantage.
Greece has implemented the epSOS open NCP and will maintain the NCP with any further extensions
whether delivered in e-SENS or in other projects (such as EXPAND). It is anticipated that the currently
expressed political commitment will also result in sustainable operation of the NCP under the legal
agreements to be established within the Subgroup.
The provision of the current cross border pilot services and the future extensions will take place
within the framework of existing European regulations, such as eIDAS, policy tools, such as eHealth
Network, and on the Directive 2011/24/EU on the application of patients’ rights in cross-border
healthcare, which has been transposed into national law. Both ePrescription and electronic patient
records are regulated by national legislation, with the latter being currently in process of
preparation.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 74
4.1.3.
Business Process Overview
The business processes to be piloted are based upon the ones described in the epSOS use cases, with
the exception of the identifications process which will be aligned to e-SENS processes. In practice, in
the epSOS Portal / OpenNCP, the component that manages the identification will be replaced by the
e-SENS eID BB. The integration of the new BB is not expected to change the original use case
business processes. The pilot will create and test the national infrastructure for the establishment of
a national service for cross sectorial eID for eHealth purposes.
4.1.4.
Pilot participants and Stakeholders
The e-SENS Greek consortium pilot will be implemented in close cooperation with the Ministry of
Health and under the co-ordination of MAREG.
ov
al
Actors involved: patients, health care providers, health care professionals, epSOS NCP, and national
organization(s) responsible for the maintenance of registries for citizens, and health care
professionals.
pr
Patients will be EU citizens visiting Greece and in the case of ePrescription/country A, also Greek
citizens visiting other EU countries.
EC
ap
Health care providers will be Greek pharmacies and eventually also public as well as private health
care providers. They will be selected, based on their location and role (e.g. touristic destinations will
be preferred), as well as the maturity of the operational status of their information systems.
g
Health care professionals will be pharmacists, doctors of medicine, and/ or nurses responsible for
healthcare treatment, which are already authorized users of clinical information systems in the need
to access remote foreign patients’ electronic health records.
Pe
nd
in
The epSOS NCP is currently hosted in AUTH (partner of the e-SENS Greek National Consortium),
which will continue to maintain it and test its evolving functionalities. It is anticipated that the NCP
and its tested extensions will migrate and run in the subsequent production mode operation phase
with AUTH technical support as needed. The STORK PEPS is managed by MAREG. AUTH team will
evolve the current OpenNCP to its last supported version, and make all the needed testing and
interoperability connectors needed for third party application to connect and exchange documents
as described in the e-SENS pilot scenarios to be implemented for Greece.
FORTH (partner of the e-SENS Greek National Consortium) will provide a patient summary access
service to end users (presentation view) in the case of the PS/country B scenario, for the involved
healthcare information system(s) that will access the NCP/ PEPS provided by AUTH/ MAREG, based
on the e-SENS scenario requiring coordinated use of eID and epSOS services.
4.1.5.
Pilot Timing
Greece is expected be able to go live at pre-production with simulated data at Q3/Q4 2015. It is
expected to be ready to go operational immediately after all domain and national pre-conditions are
met.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 75
4.2.
Pilot Description
4.2.1.
Pilot scenario
A national Patient Summary service is foreseen to be launched in early 2015; it is therefore likely that
Greece may participate in e-SENS with a full PS- country A, B service. It is however desirable that
action with actual users is taken in advance of deployment, possibly within CEF. Greece is both a
highly touristic destination and has also a highly digitized health sector. Embedding e-SENS/epSOS
functionalities into the local apps is likely to increase doctors’ buy-in and active collaboration.
The following pre-conditions will need to be met:
When in country A or B mode, Health professionals and Greek patients must be identified
and authenticated using the PEPS services and the registries managed by IDIKA (Social
Security Agency for eGovernment).

When in country A mode, a CDA document either PS or ePrescription in the epSOS format
will be created by the NCP for a test patient upon request by another NCP and will be made
available in Greek.

When in country B mode,
Test patients will be identified and authenticated by the health professionals, using
credentials required from country of origin; this identification will be used also for
discovery of their ePrescriptions and/or patient summaries
o
Test consent at the point of care will be given and will be recorded in paper as
required by Greek legislation
o
The ePrescription or Patient Summary of the patient must exist in his/ her country of
origin.
o
in
g
EC
o
Pe
nd
ap
pr
ov
al

There is a chain of trust between system actors in this process
For the purposes for running the pilots with real patients, it is considered essential that requirements
be included in bilateral or multi-lateral agreements between partnering MS and their appropriate
inclusion be verified by e-SENS in order to maintain convergence.
The processes for eP/PS are described in the domain pilot use case. The patient is identified by
electronic means against an eID provider (using the PEPS services managed by MAREG) returning a
unique eID for the patient itself. The HP's software reuses this identifier to obtain the sectorial-id
eHealth patient identifier by performing the findIdentityByTraits transaction. Once the patient is
clearly located in the remote country, HP obtains a TRC assertion from the NCPB. Using the IdA and
the TRC assertion, any epSOS transaction can then be performed.
The flow of events is depicted in the figure below.
.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 76
al
ov
Use of e-SENS and Domain-Specific Building Blocks
ap
4.2.2.
pr
Figure 25: eID flow of events
All e-SENS BBs relevant to eHealth are under consideration for piloting.
Use of National infrastructure
EC
4.2.3.
MAREG will manage the e-SENS 2.0 PEPS node for Greece.
Pe
nd
in
g
AUTH will manage the pre-production environment for the epSOS NCP node and the relevant
National connector needed based on epSOS standards for Greece, which will be subsequently passed
to IDIKA testing.
Awareness and preparatory actions with health services will be taken up in anticipation of
deployment when legal interoperability conditions are secured.
The IDIKA ePrescription and PS national services will be used, subject to the preconditions set.
4.3.
Pilot Implementation
The PS/B pilot will be implemented using the nursing and medical applications of FORTH that have
been installed and are operating in more than 20 healthcare organizations in Greece, including Crete.
Most of them are part of the Integrated Regional Health Information Systems of the 1st Healthcare
Region of Attica, the 2nd Healthcare Region of Piraeus and Aegean, and the 6th Healthcare Region of
Peloponnesus, Ionian, Epirus and West Greece.
4.3.1.
Implementation Planning
Pilot implementation will be aligned with domain pilot planning.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 77
4.3.1.1. Detailed design of pilot
Detailed design of pilot strongly depends on the eP/PS solution architecture as well as to domainlevel implementation plans. Specific technical requirements are expected to arise for implementers
as soon as they become available.
Milestone set: Q1 2015
4.3.1.2. Technical Implementation
Milestone set: Q2/Q3 2015
This phase includes the following actions:
Implementation of national extensions

Development of CDA Level 3 structure for PS (national representation)

Development of end-user GUI for ICS-M

Integration of ICS-M with national PEPS and epSOS NCP

Implementation of Schematron validators for CDA document validation (extended from
epSOS/e-SENS)

VPN connections

Certificate management

Create national MTC (Master translation catalogue) based on extended MVC

Terminology maintenance and update related to MVC/MTC

Parameterization / Configuration
Pe
nd
in
g
EC
ap
pr
ov
al

4.3.1.3. Readiness Testing and Conformance
Milestone set: Q3/Q4 2015.
This phase includes the following actions:

Installation of test environment

Implementation of test software (OpenNCP extension and BBs)

Testing of the pilot system components on national level

Testing of the pilot system on domain level (integration tests with other participant countries
– End2End testing)
4.3.1.4. Launching and Running
Once the solution has been tested and validated, it can run in pre-production environment.
Milestone set: Q4 2015
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 78
This phase includes the following actions:
Installation of pre-production testing environment

VPN Connections

Certificate Management

Training of pilot participants

Management and monitoring of the running/ operation phase of the pilot

Pilot environment maintenance – improvement of pilot implementation

Helpdesk support (1st level)

Assessment and evaluation of the pilot at national level
Pilot resources
ov
4.3.2.
al

Pilot risks and overall feasibility
EC
4.3.3.
ap
pr
To a large extend the resources needed represent effort for localization of the e-SENS/EXPAND
extensions of the epSOS assets and for running the testing and pilot and they will also involve travel
within Greece of the pilot partners. National resources as well as the results of previous national and
international projects will also support the pilot plans.
Pe
nd
in
g
The proposed pilot is intended to run over already existing National infrastructure, offering
additional functionalities and services on top of already existing integrated health information
systems. In addition, the service of receiving a patient summary from another MS will significantly
improve the continuity of care that European citizens receive in countries outside of their country of
origin (e.g. visitor in Greece).
4.3.3.1. Policy, organizational and business process factors
There are two levels of legal constraints to be taken into consideration.
1. In order to be allowed to pilot in pre-production environment, at least the agreements with
the SDOs whose standard / coding systems are used in epSOS have to be extended to e-SENS
and the renewal of the epSOS Central Service.
2. In order to have pilots with real patients, the Circle of Trust and Framework agreement to
restart service should be shaped to allow piloting also in e-SENS.
4.3.3.2. Technical factors
Specific technical requirements are expected to arise for implementers, regarding compatibility
between v1.0 and v2.0 of STORK.
4.3.3.3. Resourcing factors
Central Services costs will need to be considered at a European level.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 79
5. National Pilot Plan of Italy for UC 5.2.1
5.1.
5.1.1.
Pilot Scope
Domain Use Case to be piloted
In order to be able to describe the scope of the eHealth pilot, it should first be clarified to which
extent consolidated assets (like what is currently piloted in epSOS) may be included in the e-SENS
pilot.
ov
al
This point is also connected to the question if e-SENS is the correct framework where epSOS pilots
could be maintained alive. The subsequent question is: which of the two environments (preproduction / operation) for the two services (PS / eP).
Both PS and eP are considered in e-SENS.
pr
There are two levels of legal constraints to be taken into consideration.
EC
ap
1. In order to be allowed to pilot in pre-production environment, at least the agreements with
the SDO’s whose standard / coding systems are used in epSOS have to be extended to eSENS and the renewal of the epSOS Central Service, though, e.g. the IHE contract.
2. In order to have pilots with real patients, the Circle of Trust and Framework agreement to
restart service should be shaped to allow piloting also in e-SENS.
in
g
Assuming the relevant issues listed above are solved, it can be assumed the following Use Cases
might be piloted: Patient Summary / ePrescription
Pe
nd
1. Wave 1: LISPA, as the BB’s will be integrated and made available as OpenNCP release, it will
install first in the Pre-Production environment, afterwards, in Operation, when the eHealth
cross-border services will be made re-activated. The first BB integrated will be the nonrepudiation. The second one will be the Configuration Service and end-point detection.
2. Wave 2: LISPA, with integration of eID Building Block, if ways of integrating it in eHealth are
provided by the domain architects.
5.1.2.
National Motivation and Goals
A proposed evolution of epSOS services is to get relieved from the use of Central Configuration
Service.
Furthermore, the adoption of patient “easier” and “stronger” identification was expressed as a
request from health professions.
LISPA is a partner of STORK 2.0. The possibility of exploiting eID for overcoming the aforementioned
issues was highly supported.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 80
e-SENS gives the opportunity to extend the Use Case implemented in epSOS and in STORK 2.0,
demonstrating the possibility of implementing more efficient and robust identification of patients
from other Countries/Regions of affiliation.
5.1.3.
Business Process Overview
In epSOS the process of identifying the patient is performed in two conceptual phases:

pr
ov
al

From the Central Configuration Service, the relevant credentials for a given country are
derived; an appropriate input mask is created in the epSOS Portal in the Country of
Treatment (Country B).
When a Citizen from another Country shows up at a Point of Care:
o The Country of Affiliation (Country A) is selected and the appropriate credential mask
is displayed.
o Patient’s credentials are entered and request for identification is sent to the Country
of Affiliation.
o The Country of Affiliation returns the token to be used in the subsequent
transactions (through IHE XCPD profile) to request the document.
ap
In the case of e-SENS, the patient identification process is performed by the eID Building Block, which
returns the token for IHE XCPD transaction.
EC
In practice, in the epSOS Portal / OpenNCP, the component that manages the identification is
replaced by the eID BB. The final decision on if and how the eID BB will be included is conditioned by
the assessment and the central implementation under the EXPAND Project governance of eHealth
OpenNCP.
Pe
nd
in
g
The performed assessments exclude the possibility for Italy to adopt the eDelivery BB for the eHealth
5.2.1 pilot, due to, in primis, legal reasons and for incompatibility with the currently implemented
technical cross-border infrastructure.
The future potential Pilot Case could be the inclusion of other BB to solve problems known from the
past:

Improve transaction non repudiation, by enforcing the audit process

Improve patient access to audit trail

Reduce effort to maintain central configuration service

Increase trust on document contents through eSignature.
5.1.4.
Pilot participants and Stakeholders
The basic requirements considered as a pre-requisite, is that e-SENS adopts for the eHealth eP/PS
Use Cases, the epSOS Testing Strategy and approval process, described in the epSOS deliverables
D3.9.2, D3.10.1, D3.C.1 and D3.C.2 and in the legal requirements set in epSOS workpackages WP2.1
and 2.2.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 81
These requirements include Level 0 Conformance Gates (to be allowed to participate to the preProjectathon), Level 1 Conformance Gates (to be allowed to be included in the Pre-Pilot Testing
Environment) and Level 2 Conformance Gates (to be allowed in Operation with real patients), covers
legal, organisational, security, technical and semantic aspects, with assure the safeguard of the PPT
environment and the patient safety, privacy and security in operation.
The Italian representative for eHealth (LISPA) commits to the every possible effort to create and
cooperate in the Pre-Pilot-Testing (PPT) environment (defined in epSOS as the quality assurance
environment before Operation).
Considering the experienced time needed to arrive to fulfil all Level 2 Conformance Gates, this makes
hard believe (but it does not exclude at least for the Non-repudiation BB) the IT pilot will be able to
exchange real patient data within the scope of the pilot foreseen for e-SENS.
al
Although pilot will be run in PPT, we should remember that all the stakeholders are involved:
The Regional Healthcare Institution, which defined and applies the (e-)Health governance
rules

The HealthCare service provider and health professional, involved in the definition of the
clinical contents and assess clinical correctness in the end-2-end functional testing

Patient representatives might be involved to assess user’s suitability
Pilot Timing
EC
5.1.5.
ap
pr
ov

in
g
The Italian Pilot aims to start during the second quarter of 2015, if coincident with Wave 1. In order
to allow the pilot to start a full and detailed plan with concrete commitments will need to be
available. That will depend much in the status of the Building Blocks and in the possibility of keeping
the epSOS pilot running.
Pe
nd
The implementation strategy should be based on a jointly central development of adaptation of BB
and integration within the OpenNCP. This centralised process should be performed under the
governance of EXPAND Maintenance Shops, to allow the backward compatibility with the OpenNCP
and assure a forward coherence with next releases of the OpenNCP.
Lombardy will afterward deploy in its NCP the OpenNCP enriched with the e-SENS BBs.
The Italian pilot site will be running in the third quarter of 2015 and first quarter of 2016 with a
possible approach to a scenario with simulated patients.
As described in Błąd! Nie można odnaleźć źródła odwołania., if Conformance Gate Level 2 criteria
are met, real patients will be included, at least for Wave 1.
5.2.
5.2.1.
Pilot Description
Pilot scenario
Italy will pilot the Patient Summary Country A and Country B and ePrescription/eDispensation
Country A use-cases with the possibility to pilot ePrescription/eDispensation Country B if this
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 82
scenario will be implemented. Pilots will be operationalised taking advantage of the eID Building
Block for patient identification and additional Building Blocks that can be available during the
execution of the Pilot phase. All piloting operations will be implemented in the light of the previous
experience gained during the epSOS large scale pilot.
Use Case Patient Summary Country A: to provide the Patient Summary to Italian (Lombardy) citizens
to be used for specialists’ consultation and for cross-border continuity of care. In this use case the
following requisites must be accomplished:
Patients must be able to give their consent to provide their Patient Summary for access
from/within e-SENS;

Foreign/Accessing health professionals must be authenticated and authorized to search for
patients’ identity and to gain access to the PS;

The identity of the patient must be unequivocally determined; the eID service from e-SENS,
integrated into the NCPs will provide to the Lombardy NCP the assertion of the identity of
the Lombardy patient seeking health care abroad;

If the authorisation is successful, the Patient Summary must be transferred from the shared
electronic health record of the patient to the authenticated foreign health professional.
ap
pr
ov
al

EC
Use Case Patient Summary Country B: to provide the visiting EU citizens with the possibility that
their PS is retrieved by a healthcare professional at point of care in Italy (Lombardy). Functional
requirements which need to be implemented at national level include:
Health professional must be identified and authenticated in the Country of Treatment
(Country B);

The Patient must be identified through manual Id entry or seamless entry of eID, through the
eID service from e-SENS, which provides the assertion on patient’s identity to the Country A
NCP;

The Patient must be searched (by credentials required from country of origin);

Patient consent at the point of care may be given;

If authorisation is successful, the Patient Summary must be retrieved, translated/translated
and visualized to the Lombardy Health Professional.
Pe
nd
in
g

Use Case ePrescription/eDispensation Country A: to provide the eP to Italian (Lombardy) citizens to
be used for dispensation abroad. For this use case:

Patients must be able to give their consent to provide their Patient Summary for access
from/within e-SENS;

Foreign/Accessing health professional (pharmacist) must be authenticated and authorized to
search for patients’ identity and to gain access to the PS;

The identity of the patient must be unequivocally determined; the eID service from e-SENS,
integrated into the NCPs will provide to the Lombardy NCP the assertion of the identity of
the Lombardy patient seeking health care abroad;
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 83

If the authorisation is successful, the list of valid ePrescription is sent to Country B.

The medication is dispensed to the patient: the information is presented in the pharmacist’s
language. The pharmacist is finally able to send information to the Country of Affiliation
about the dispensation made and the patient information is updated.
In the case also ePrescription Country B service will be made available, the following Use Case will be
implemented:
Use Case ePrescription/eDispensation Country B: to provide the visiting EU citizens with the
possibility that their eP is retrieved and dispensed by a healthcare professional at point of care in
Italy (Lombardy). Functional requirements which need to be implemented at national level include:
Health professional must be identified and authenticated in the Country of Treatment
(Country B);

The Patient must be identified through manual Id entry or seamless entry of eID, through the
eID service from e-SENS, which provides the assertion on patient’s identity to the Country A
NCP;

The Patient must be searched (by credentials required from country of origin);

Patient consent at the point of care may be given;

If the authorisation is successful, the list of valid ePrescription is received from Country A.

The pharmacist, with support of the patient, selects the ePrescription to be dispensed.

The medication is dispensed to the patient: the information is presented in the pharmacist’s
language. The pharmacist is finally able to send information to the Country of Affiliation
about the dispensation made and the patient information is updated.
Use of e-SENS and Domain-Specific Building Blocks
Pe
nd
5.2.2.
in
g
EC
ap
pr
ov
al

e-SENS BB foreseen to be used:
1. eID : to identify citizens, high priority adopted in Wave 2
2. Any other BB that may be adopted should only be considered after the first BB is fully
adopted. Priority will be given to:
a. eSignature, if aimed to increase the trust and non-repudiation of eP/eD and PS
documents (high interest, but to be assessed if made available for Wave 2 in the
OpenNCP)
b. Non-repudiation (Wave 1)
c. Configuration service (lower priority, possibly wave 1)
e-SENS BB foreseen not to be used by the Italian eHealth pilot: eDelivery based on AS4, as currently
specified, for non-fulfilment of legal constraints and of technical requirements of current crossborder implementation.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 84
5.2.3.
Use of National infrastructure
LISPA is managing the Lombardy Electronic Health Record system (Sistema Informativo Socio
Sanitario: SISS)
The infrastructure implemented for epSOS will be exploited and updated for e-SENS pilot.
5.3.
Pilot Implementation
5.3.1.
Implementation Planning
The implementation of the pilot site in Italy will entail the following steps, some of them already in
place being deployed during the epSOS large scale pilot:
Preparation of technical aspects, e.g. to develop technical implementation of components
connecting national infrastructure to epSOS/e-SENS, including VPN connection

Contractual/Legal agreements for the localisation and running of the pilot action

Clinical aspects – Patient consent management, identification / authentication /
authorisation / certificate management

Preparation of organisational aspects, e.g. develop national communication strategy,
establish NCP organization, operational management (incident, change, configuration,
security management)

Semantic issues (Master Translation/Transcoding Catalogue [MTC]), PS/eP dataset availability
assurance (no impact on e-SENS)

Physical and process data security

Preparation of Monitoring and Evaluation and execution

Preparation of test (Testing in PreProd-Testing environment)

Identification of risks and constraints

Training measures design and implementation

Installation of pre-production testing environment

Installation of production environment

Pilot environment maintenance and improvement

Help-desk support.
Pe
nd
in
g
EC
ap
pr
ov
al

5.3.2.
Pilot resources
For the Italian pilot site deployment, the following professional profiles will be envisaged:

Project Manager: Marcello Melgara, acting also as:
o
Health Term administrator and semantic manager
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 85
Legal & Administrative Manager: Roberto Zuffada, considering also:
o


Patient consent administrator (Security and Privacy function)
Marketing & Communication Manager, considering also:
o
Training Management
o
Evaluation Management
Technical Manager: Luca Pagliara, acting also as:
5.3.3.
o
Architect solution manager,
o
NCP adaptation responsible
Pilot risks and overall feasibility
al

ov
5.3.3.1. Policy, organizational and business process factors
pr
At this stage, the following legal constraints should be taken into account:
EC
ap
1. In order to be allowed to pilot in pre-production environment, at least the agreements with
the SDOs whose standard / coding systems are used in epSOS have to be extended to e-SENS
and the renewal of the epSOS Central Service. This will be jointly solved with EXPAND
Project.
g
2. In order to have pilots with real patients, the Circle of Trust and Framework agreement to
restart service should be shaped to allow piloting also in e-SENS. This will be jointly solved
with the DG-Santé eHealth Network sub-group, signing the Temporary Legal Agreement.
in
5.3.3.2. Technical factors
Pe
nd
Specific technical requirements are expected to arise for implementers, regarding compatibility
between v1.0 and v2.0 of STORK.
However, they will not be specific to the Lombardy pilot, but centrally solved by the EXPAND
Technical Maintenance Shop and e-SENS WP6.3 / WP5.2 as a whole.
5.3.3.3. Resourcing factors
Planned resources for LISPA (in charge for the Italian eHealth pilot) might be not enough for covering
the complexity of a pilot operation in full production with real patients. Central Services costs will
need to be considered at a European level and not charged to the Lombardy pilot.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 86
6. National Pilot Plan of Luxembourg for UC 5.2.1
6.1.
6.1.1.
Pilot Scope
Domain Use Case to be piloted
Luxembourg will pilot only the Patient Summary use case. ePrescription use case was considered as
interesting for Luxembourg but currently difficult to pilot.
6.1.2.
National Motivation and Goals
ap
pr
ov
al
The piloting in e-SENS is the next step for Luxembourg to foster European wide cross-border eHealth
services and a logical next step to the epSOS piloting operations. Luxembourg is embedded in the
“Greater Region” (European grouping of territorial cooperation composed by Belgium, Germany,
France and Luxembourg), and has a lot of commuters from these three neighbouring countries, who
are working on a daily basis in Luxembourg. Additionally Luxembourg has a huge community of
resident coming from Portugal.
Pe
nd
in
g
EC
Luxembourg cooperates closely with its boundary countries to ensure its residents get high level of
medical expertise. In 2012, the Medical Control of Social Security authorised 17 778 cases of
transfers for abroad care under the EEC Regulation 883/2004. In 2007, the patients transferred have
been mainly treated in Germany (55%), in Belgium (25%), and in France (16%). These abroad cares
with other services under the Directive 2011/24/UE represented 19,1% of the total expenses of the
main Luxembourgish health insurance organisation (CNS). Besides, abroad care has increased to
14,8% in 2012.12 Although these bordering countries are not participating in this PS pilot, we hope
that this voluntary work will be later used widely.
Luxembourg will take the opportunity to pursue the enhancement of the cross border services
started in epSOS to enable and facilitate cross-border medical information exchange services.
Luxembourg is interested to integrate the eID building block in these services.
The participation of such European initiative is important to elaborate and sustain European medical
services. For instance, the usage of circle of trusty national contact point in the framework of
European projects to implement the exchange of medical information, should prevent the
participating countries from the need to create bilateral agreements and different interfaces for the
exchange of data.
Participating organizations:
The Agence eSanté is contributing in WP5.2. The Agence eSanté is in charge of the management of
the eHealth platform in Luxembourg for sharing and exchanging medical information electronically.
12
Rapport général sur la Sécurité sociale 2012 :
http://www.mss.public.lu/publications/rapport_general/rg2012/rg_2012.pdf#page=104
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 87
The Agence eSanté is also responsible for the organization and coordination of national and crossborder exchanges.
The research centre LIST is contributing in several WPs in e-SENS (WP2, WP3, WP5.2 and WP6.2) and
will support the work of the Agence eSanté in the WP5.2.
6.1.3.
Business Process Overview
The business process expected is nearly the same as in the use case of the Patient Summary of
epSOS. The same actors are involved: patient, health care provider and NCPs.
al
The main differences from an end user perspective will be the ability to seamlessly identify a foreign
patient through a various set of eID media from the current manual identifier entry to the reading of
a foreign smartcard or any media.
6.1.4.
ov
More information on the planned business process is described in the Pilot Scenario description.
Pilot participants and Stakeholders
ap
pr
Due to the current legal issue, Luxembourg considers also that it’s worth to start piloting only with
test data and real doctors. When legal issue will be solved by the eHealth network, we will go to real
patient piloting in wave 3.
This implies 2 recruitments phases.
EC
1. Phase. Test patient data
in
g
We need to recruit only few doctors to validate the service. We aim to recruit 3 doctors. Doctors
with ability to read medical text in the language of one the participating nation (Greek, Portuguese or
Italian or Spanish) will be fostered. This will enable the validation of the translation of the Patient
summary. Each of this doctor will have to create one realistic test patient summary.
Pe
nd
2. Phase. Real patient data
The recruitment of the participants will start when the legal issue will be solved and the solution
enough mature to be presented to these actors. The target groups are the independent health
professionals and hospitals.
Note: For the time remaining in the project, it seems unrealistic to establish a "real patient data"
framework with DPA declaration and etc. So we are more in favour to focus on the building of the
new robust technical infrastructure with "real but anonymized patient data" and to stay focus. When
the service will have shown robustness in pre-production, we may reconsider our position.
6.1.5.
Pilot Timing
The Pilot will start in Wave 2. Technical resources have been allocated for Q4/2014. Luxembourg
should be able to pilot Q2/2015.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 88
6.2.
Pilot Description
6.2.1.
Pilot scenario
The Patient Summary use-case (defined in e-SENS) will be implemented with the intention to provide
the services as country of origin (country A) and as country of treatment (country B) of patients.
Country A:

Residents of Luxembourg, visiting another European country, will be able to provide access
to their Patient Summary to support their treatment by a health professional at the point of
care.

Functional requirements
Patients must be able to give their consent to provide their Patient Summary for
access from/within e-SENS
o
Foreign/Accessing health professionals must be authenticated and authorized to
search for patients’ identity and to gain access to the PS.
o
The identity of the patient must be unequivocally determined
o
If the authorization is successful, the Patient Summary must be transferred from the
shared electronic health record of the patient (called in Luxembourg DSP: dossier de
soin partagé) to the authenticated foreign health professional.
EC
ap
pr
ov
al
o
Country B:
Patients from other European countries should be able to provide access to their patient
summary, when being in treatment by a health professional in Luxembourg.

Functional requirements which need implementation on national level:
o
Health professional must be identified and authenticated in the country of treatment
o
The Patient must be identified through manual Id entry or seamless entry of eID.
o
Pe
nd
in
g

The Patient must be searched (by credentials required from country of origin)
o
Consent at the point of care may be given
o
If authorization is successful, the Patient Summary must be retrieved,
translated/translated and visualized.
Parts of these functionalities are already implemented with the epSOS OpenNCP and will be used or
extended to be compatible with the BBs in e-SENS.
For the BB for eID identification and authentication, the original use case will be adapted just after
the authentication of the health professional against NCP B. The patient is identified by electronic
means against an eID Provider (STORK / FutureID) returning a unique eID for the patient itself. The
HP's software reuses this identifier to obtain the sectorial-id eHealth patient identifier by performing
the findIdentityByTraits transaction. Once the patient is clearly located in the remote country, HP
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 89
obtains a TRC assertion from the NCPB. Using the IdA and the TRC assertion, any epSOS transaction is
performed.
ap
pr
ov
al
The flow of events is depicted below.
6.2.2.
EC
Figure 26: eID flow of events
Use of e-SENS and Domain-Specific Building Blocks
6.2.3.
Pe
nd
in
g
Luxembourg would like to assess the feasibility to use an instantiation of the generic e-SENS eID BB
that will enable to seamlessly identify a foreign patient electronically. We wish also enhance the
security of the process thanks to Non-Repudiation Solution Architectural Template and Capability
and Location Lookup Architectural Building Block.
Use of National infrastructure
Luxembourg, through Agence eSanté, is equipped with a national services platform (eHealth
platform) for sharing and exchanging medical information. The creation and integration of an NCP is
part of the eHealth platform specification. While the Luxembourgish NCP is already available as a
separate service, accessible via a web interface through the eHealth platform and medical practice
software, a tighter integration with the eHealth platform is foreseen for Q2 2014, providing health
professionals with a fully integrated service.
For piloting the Patient Summary use case, it is intended to reuse the NCP and benefit from its
integration with the national eHealth platform, on a functional but also on a technical and
architectural level.
The NCP has been developed and tested in the context of the epSOS project.
The national eHealth platform (www.esante.lu) is one of the concrete results of the national eHealth
program in Luxembourg initiated in 2006. One of the major service is the DSP (Dossier de Soins
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 90
Partagé – shared electronic health record) but it also provides services like end-to-end encrypted
secure messaging for medical information, collaborative tools for medical interest groups, Healthcare
Provider Directory, SaaS HIS, a portal with SSO to access all services (incl. epSOS) etc. The eHealth
platform aims to be compatible with cross-border, European, and international partners, so it is
naturally compatible with – and uses – international standards and norms like IHE XDS-b profile, HL7
v2.5, HL7 CDA R2, LOINC etc.
6.3.
Pilot Implementation
6.3.1.
Implementation Planning
Description
pr
Tasks
ov
al
The implementation planning for Luxembourg has been drafted with the perspective that the
Domain provided all the material needed to implement the PS use case enhanced by the new BB of
e-SENS. The table below lists the national task to perform for the implementation of the pilot with
real patient data (with test data only some tasks need to be withdrawn).
1.1
General piloting project management tasks
1.2
Meetings and Tcons
2. Prospect/Lead/Commitment tasks
ap
1. Project management tasks
Translate material (e.g. a flyer, ppt) to explain the e-SENS PS use case and the project
2.2
Informative meetings for Motivation of points of care
2.3
Localisation of FWA (Framework agreement)
2.4
National contract creation for PoC
2.5
Security Audit of PoC
in
Pe
nd
3. Enabling pilot
g
EC
2.1
3.1
Installation of test environment
3.2
Implementation of test software (OpenNCP extension and BBs)
3.3
Implementation of national extensions
Health professional authentication as Country B
Patient identification (discovery) as Country A
Transcoding of national patient summary to epSOS/e-SENS patient summary
OPT-IN (electronically) consent by patient for participation in project
Portal - B modifications
3.4
Development of CDA Level 3 structure for Patient Summary (national representation)
3.5
Implementation of Schematron validators for CDA document validation (extended from epSOS/e-SENS)
3.6
VPN connections
3.7
Certificate management
3.8
Create national MTC (Master translation catalogue) based on MVC
3.9
Terminology maintenance and update related to MVC/MTC
3.10
Parameterization / Configuration
3.11
Testing in preProd environment
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 91
Testing of local components
Integration testing with national extensions
End2End testing
3.12
Creation of Helpdesk support
3.13
Creation of training material
3.14
Training of health professionals
3.15
Information and negotiation with DPA (CNPD)
4. Running pilot
Installation of production environment
4.2
VPN connections
4.3
Certificate management
4.4
Monitoring and Evaluation
4.5
Pilot environment maintenance
4.6
Helpdesk support
ov
Pilot resources
TOTAL
pr
6.3.2.
al
4.1
ap
In Luxembourg, use case PS (UC 5.2.1) is piloted by the Agence eSanté in association with LIST (that
supports the work of Agence eSanté).
Pilot risks and overall feasibility
EC
6.3.3.
g
6.3.3.1. Policy, organizational and business process factors
in
No organizational obstacles are identified as the use case works within epSOS framework.
Pe
nd
6.3.3.2. Technical factors
Technical obstacles have still to be assessed.
6.3.3.3. Resourcing factors
Agence eSanté and LIST will work together to implement nationally the new BB. No resourcing
obstacles are identified. Nevertheless, a call to a subcontractor is still possible to help the
implementation. The technical resource planned to work on implementation of BB nationally is
leaving the LIST in April. We are looking for an alternative solution. This should not have major
impact on the national pilot implementation but may create a delay. Another technical resource will
be available beginning of May 2015, it could be one solution.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 92
7. National Pilot Plan of Portugal for UC 5.2.1
7.1.
7.1.1.
Pilot Scope
Domain Use Case to be piloted
Portugal, within the eHealth domain, intends to pilot the Patient Summary use case (UC5.2.1), based
on the epSOS specifications. Portugal aims to enhance the maturity of the epSOS pilot by adding the
eID BB to the national eHealth gateway, providing a seamless error prone and user-friendly
mechanism for patient identification.
pr
ov
al
The Portuguese pilot also foresees the adoption of other two e-SENS BB features: i) the nonrepudiation (or Evidence Emitter) in order to provide evidences for legal/organisational disputes that
may arise with the usage of the service; ii) the trust establishment and configuration services in order
to provide a CED aligned strategy for distributing configurations as an alternative to epSOS Central
Service customized approach.
National Motivation and Goals
EC
7.1.2.
ap
The pilot plan does not preview the exchange of data in a real life situation.
in
g
The Ministry of Health in Portugal within its efforts to review its national health information strategy,
created by the end of 2011, a Commission for Clinical Informatics, which is since then in charge of the
national project “Plataforma de Dados da Saúde – PDS” which constitutes the Portuguese Electronic
health record platform and is aiming to provide a set of services, namely, patient summary, patient
access, ePrescription, booking of appointments, among others.
Pe
nd
Since June 2012, this Commission was formally made responsible for cross-border collaboration
efforts, which include the participation in the epSOS pilot and other major eHealth interoperability
projects like Trillium Bridge and e-SENS. Since August 2014, the Portuguese Ministry of Health
published a new law that establishes rules for the access to cross-border healthcare and promotes
cross-border cooperation, transposing the Directive in 2011/24 / EU of the European Parliament and
European Commission.
The epSOS Patient Summary service was provided as a logical extension of the national facilities
already in place to all doctors in the public sector – National Health Service - as well as to all
Portuguese citizens except those residing in the islands of Madeira and Azores, because these
operate under their regional health systems.
The Portuguese eHealth pilot’s aim within e-SENS is to improve the clinical information exchange
services that have been defined in epSOS in order to make them more user-friendly and sustainable
by aligning the underlying technological infrastructure with the CEF Building Blocks.
The plan for enhancing the epSOS cross-border services relies on adding the eID for patient
identification, non-repudiation (Evidence Emitter) for legal disputes and Trust establishment
mechanism to improve the distribution of services metadata and configurations.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 93
7.1.3.
Business Process Overview
The Portuguese pilot will be on Patient Summary, both as Country A (country of origin) & B (country
of treatment), at national level, interconnecting about 100 Hospitals and 360 Primary Healthcare
units from the continental part of Portugal as a universe of around 9 million inhabitants.
In 2011, by Decree-law n. 108/2011, of 17th of November, the ICT department of ACSS was
transferred to SPMS (Serviços Partilhados do Ministério da Saúde, a public enterprise for shared
services of Ministry of Health - the unique ICT department for MoH) and was also defined that ACSS
could subcontract services to no one else than SPMS. It means that by law, ACSS acquires services to
SPMS based on an annual contract program, based on public procurement principles, taking into
account that SPMS is a state owned enterprise (SOE).
ov
al
ACSS is the Portuguese National Authority, as public administration entity with the responsibility of
pilot national coordination among other activities related to legal and regulatory issues,
standardization or policy activities, disclosure of the initiative and other efforts that might be
deemed necessary.
ap
pr
Since September 2014, SPMS - Serviços Partilhados do Ministério da Saúde, E. P. E, was formally
endorsed and empowered by the Ministry as the National Authority responsible for eHealth
cooperation.
EC
SPMS is the technical partner with the main responsibility of component and pilot implementation,
operation and evaluation and for setting-up and maintenance of the NCP.
Pe
nd
in
g
For the e-SENS eHealth pilot, the Portuguese approach for Patient Summary is built upon the PrePilot-Testing (PPT) environment. This implies the creation of Patient Summaries with fake
information that could be exchanged and translated by the NCP. This approach relies on the
existence of epSOS Central Services in order to: a) retrieve other countries configurations (e.g. end
points, user identification data entry masks); and b) terminology catalogues for translation and
transcoding information.
7.1.4.
Pilot participants and Stakeholders
The Portuguese representative for eHealth (SPMS) commits to the every possible effort to create and
cooperate in the Pre-Pilot-Testing environment (defined in epSOS as the quality assurance
environment before Operation).
Although we believe it would have been possible to use existing legal agreements, it is less likely that
real patient data will be shared under the scope of the pilot foreseen for e-SENS.
In this eHealth pilot, there are several actors involved, namely: patients, healthcare professionals,
healthcare providers and the PT eHealth NCP. The expected benefits for each actor are:

Patient
o
Security on healthcare providing due to patient info access;
o
Tranquillity feeling by the awareness of easier communication at PoC;
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 94
o
o
Conditions for providing better healthcare overcoming language difficulties with
foreign patients and overview of clinical info, allowing better diagnosis and
treatment;
o
Improvement of the awareness for the importance of standard documentation in
local records.
Healthcare provider
o
7.1.5.
To ease healthcare delivery and make it safer for patients while abroad or for PT
healthcare professionals when dealing with foreign patient.
al

Healthcare professional
Pilot Timing
ov

Empowerment - more info to take a better “participation” on her/his health; access
to her/his own health information;
pr
The Portuguese pilot aims to work on stages, according to the e-SENS BB availability. Foreseen stages
and timings, during 2015 and 2016:
2015 1st Quarter: introduction of Non-Repudiation (Evidence Emitter);

2015 2nd Quarter: introduction of trust establishment and configuration services;

2015 3rd Quarter: introduction of eID;

2015 4th Quarter and 2016 1st Quarter: run the pilot in full scope, with a possible approach
to a scenario with simulated patients;
g
EC
ap

in
This time plan has in consideration two high level inter-dependencies:
The availability of e-SENS Building Blocks;

The Portuguese infrastructure for eID, whose responsibility and ownership are established
outside SPMS, by AMA (e-SENS National Project Coordinator).
7.2.
7.2.1.
Pe
nd

Pilot Description
Pilot scenario
Portugal plans to pilot the Patient Summary use case (UC5.2.1) taking advantage of the eID BB for
patient identification and additional BBs that can be available during the execution of the pilot.
The national pilot will be implemented so that Portugal can provide services as country of origin
(Country A) and services as destination country (Country B).
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 95
HealthCare
Profissional
Portal
Patient
NCP B
eID
NCP A
National
Healthcare
Infraestructure
Patient Look For Health Assistance
Get Patient Identification (eID)
Return PatientId
Request authentication
Send Credentials
Authenticated
Request Patient Summary (Using PatientId)
Request Patient Summary (Using PatientId)
al
Request Patient Summary (Using PatientId)
ov
Return Patient Summary
Return Patient Summary
ap
pr
Return Patient Summary
As country A:
in
Functional requirements
o
Patients must be able to give their consent to provide their Patient Summary for
access from/within e-SENS.
o
Foreign/Accessing healthcare professionals must be authenticated and authorized to
search for patient’s identity and to gain access to the PS.
o
The identity of the patient must be unequivocally determined.
o
If the authorization is successful, the Patient Summary must be transferred from the
shared electronic health record of the patient to the authenticated foreign health
professional.
Pe
nd

g
EC
A national patient in other European country needs to be viewed by a healthcare professional.
He/she provides his/her national identification card to be read by electronic means. After positive
confirmation of the patient identification, the healthcare professional will have access to the Patient
Summary.
As country B:
A healthcare professional in Portugal should be able to access Patient Summary from patients from
other countries in Europe.

Functional requirements which need implementation on national level:
o
The healthcare professional must be identified and authenticated in the country of
treatment.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 96
7.2.2.
o
The patient must be identified through manual Id entry or seamless entry of eID.
o
The patient must be searched (by credentials required from country of origin).
o
Consent at the point of care may be given.
o
If authorization is successful, the Patient
translated/translated and visualized.
Summary
can
be
retrieved,
Use of e-SENS and Domain-Specific Building Blocks
e-SENS BBs foreseen to be used:
Non-repudiation (or Evidence Emitter), to support legal disputes with evidences.

Trust Establishment and Configuration Services, to improve the distribution of services
metadata and configurations, if possible in a decentralized architecture.

eID (Electronic identification), to identify citizens in a more secure and user-friendly
approach.
Use of National infrastructure
ap
7.2.3.
pr
ov
al

The national infrastructure foreseen to be used is the following:
Portuguese eHealth National Contact Point (based on epSOS OpenNCP reference
implementation);

National implementation and repositories of the Patient Summary Service (namely, PDS and
RCU2);

Reference terminology (translations and transcoding) for Patient Summary: MVC-MTC;

The Portuguese PEPS managed by AMA (e-SENS National Project Coordinator).
7.3.
7.3.1.
Pe
nd
in
g
EC

Pilot Implementation
Implementation Planning
The implementation planning for Portugal has been drafted having in consideration the interdependencies already identified (e.g. e-SENS BB, e-SENS eHealth and PT PEPS) and relying on the
statement that all the engaged stakeholders will provide, in agreed timelines, the material needed to
implement the PS use case enhanced by the new BBs of e-SENS. The table below lists the national
task to perform for the implementation of the pilot.
Tasks
1.
Description
Project Management Task
1.1.
General Piloting Project Management Tasks
1.2.
Meeting and Tcons
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 97
2.1.
Installation of test environment
2.2.
Implementation of test software (OpenNCP extension and BBs)
2.3.
Implementation of national extensions
2.4.
Development of CDA Level 3 structure for Patient Summary (national representation)
2.5.
Implementation of Schematron validators for CDA document validation (extended from epSOS/e-SENS)
2.6.
VPN connections
2.7.
Certificate management
2.8.
Create national MTC (Master translation catalogue) based on MVC
2.9.
Terminology maintenance and update related to MVC/MTC
2.10.
Parameterization / Configuration
2.11.
Testing in PreProd-Testing environment
Installation of production environment
3.2.
Monitoring and Evaluation
3.3.
Pilot environment maintenance
7.3.2.
ov
3.1.
al
Running Pilot
Pilot resources
pr
3.
Enabling Pilot
ap
2.
EC
In Portugal, SPMS will provide all the necessary resources to piloting use case 5.2.1. The effort
assigned to Portugal will be spent on one Project Manager, one Solution Architect and two technical
resources.
Description
Project Manager (1 person)
Manage the implantation of the national Pilot. Will coordinate
g
Role
in
development team and be responsible to keep informed the
stakeholders about the evolution of the project.
Responsible for the technical architecture of the Pilot. Will
Pe
nd
Solution Architect (1 person)
promote the use of best practices and will take part on the
decisions about implementation guidelines.
Technical Resources (2 person)
Total
7.3.3.
Will develop the National Pilot
Pilot risks and overall feasibility
7.3.3.1. Policy, organizational and business process factors
From an organizational point of view, we have identified the following risk:

National PEPS availability for eID, since the deployment of this service is not inside SPMS
scope of responsibility.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 98
7.3.3.2. Technical factors
There are several risks in the implementation of this pilot, as identified below:

Implementations of the BBs that we aim to include in PT Pilot, for example Non-Repudiation
and eID. The development of those BBs are dependent on third parties;

OpenNCP (and Community): Not having the means to bring together the people to make the
needed changes as well as to support National Pilots adopting new releases.
7.3.3.3. Resourcing factors
Pe
nd
in
g
EC
ap
pr
ov
al
SPMS are allocating all the needed resources to this pilot; we judge that this will not be a constraint
to the overall success of this.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 99
Pe
nd
in
g
EC
ap
pr
ov
al
ANNEXES
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
100
Annex I: Pilot Plan
DESCRIPTION
START
PLAN
D-14
1
1,1
1,3
Get in touch with the rationale behind the eSENS WP5.2 eHealth pilot Plan for eHealth,
namely concerning; structure, timings, and
activities; and confirm Member State ability to
commit to the plan proposed. The plan MUST
clear communicate the expected outcomes so
that all stakeholders may manage
expectations from the beginning.
Study epSOS Req. and Spec., and update them Understand the Patient Summary and
(in EXPAND) accordingly to e-SENS
ePrescription (eDispensation) use cases,
namely the complete workflows and the
implications introduced by the adoption of the
e-SENS Building Blocks (having as baseline the
epSOS specifications).
Evaluate whether OpenNCP and Central
Deep analyse and describe the impact of the
Services can be reused
incorporation of each e-SENS proposed
Building Block or BB feature is such a way that
we can move from architectural perspective to
implementation level with clear specifications
for MS or Communities to implement. With
this input in hand a unbiased analysis can be
made in order to understand the level of
reusability possible with epSOS NCP reference
implementation and central services
1
9
1
9
1
9
F-15
M-15
A-15
M-15
J-15
J-15
A-15
S-15
O-15
N-15
D-15
Holidays
2
3
4
5
J-16
F-16
M-16
holidays
6
7
8
9
10
11 12 13
14
15 16 17
18
19 20 21 22
23
24 25 26
27 28 29 30
Pe
nd
in
g
1 - Baselining
1,2
Understand e-SENS Pilot Scope and Plan
J-15
DURATION Weeks
31 32 33 34 35
36
37 38 39
va
l
ACTIVITY
ap
pr
o
Task ID
EC
PLAN
Phase
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
101
40
41 42 43 44
45
46 47 48
49
50 51 52
53
54 55 56 57
58 59 60 61
62
63 64 65
66
67 68 69 70
PLAN
D-14
1
2,2
2,3
2,4
2,5
2 - Non-Repudiation
2,6
Restart epSOS Central Services (migration
activities should be considered)
NCP BSP (27002:2005) alignment with ISO
27002:2013
Requirements and recommendations list
update and alignment with the updated
legislature (eIDAS, Patients’ Rights, CrossBorder HC, Guidelines on PS & eP, etc.)
Adding e-SENS: Non-repudiation BB feature
(into OpenNCP)
OpenNCP QA and Release
MS instantiate OpenNCP (update or fresh
install)
2,7
MS Pre-Connectathon Testing
2,8
MS Connectathon Testing
2,9
Sustainably Fix Connectathon issues
2.10
2,11
2,12
PILOTING - Stage 1
Member states instantiate the National
Contact Point based on the OpenNCP
reference implementation, provided by epSOS
and the OpenNCP Community (currently
steered by EXPAND)
The testing step aims at gathering strong
evidenced of compliance with specifications
and profiles (if possible, collected face to face
by independent entity) from the several
Member States piloting in e-SENS.
The Audit step aims at gathering, from each
MS willing to pilot, a readiness report on the
several dimensions of the pilot (technical,
semantic, security, organizational and legal – if
applicable)
This step identifies the moment where 2 (two)
or more MS reach a readiness level where the
minimal conditions have been achieved for
exchanging clinical data.
The current plan proposes an agile way to
“Start Piloting” namely by suggesting that
pilots may start before all the e-SENS Building
Blocks of BB feature are in place.
The proposed agile way, points to a plan
where MS could re-start the epSOS PPT
environments without any changes to the
epSOS implementation. From then on, any
improvement could be built on top of that
working infrastructure and services.
10
8
10
8
10
8
10
4
14
2
16
3
19
2
21
1
22
2
24
25
1
1
26
1
3
4
5
M-15
A-15
M-15
J-15
27
J-15
A-15
S-15
O-15
N-15
D-15
J-16
F-16
M-16
holidays
6
7
8
9
10
11 12 13
14
15 16 17
18
19 20 21 22
23
24 25 26
27 28 29 30
Pe
2,13
OpenNCP QA and Release
MS update local instalattion of NCP
MS perform Regression Testing
In order to assure the epSOS architecture all
needed conditions to work, the first step is
find the needed conditions to restart the
current central services. This step will allow
MS to technically restart exchange of data by
allowing the automatic synchronization of
infrastructural communications settings.
F-15
Holidays
2
nd
2,1
J-15
DURATION Weeks
31 32 33 34 35
36
37 38 39
va
l
START
ap
pr
o
DESCRIPTION
EC
ACTIVITY
g
Task ID
in
PLAN
Phase
20
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
102
40
41 42 43 44
45
46 47 48
49
50 51 52
53
54 55 56 57
58 59 60 61
62
63 64 65
66
67 68 69 70
START
PLAN
D-14
1
3,1
3 - TrustEstab + ConfigServices
3,2
3,3
3,4
3,5
3,6
3,7
3,8
3,9
3.10
3,11
3,12
4 - Patient eID
4,1
4,2
4,3
4,4
4,5
4,6
4,7
4,8
4,9
TEST new CS infrastructure
Deploy new CS infrastructure
Integration TESTING with OpenNCP
OpenNCP QA and Release
MS update operation model according to new
paradigm of CS
MS update local installation of NCP
MS perform Regression Testing
PILOTING - Stage 2
Understanding new BB specification and
implementation impact
Adding e-SENS: eID (into NCP)
Integration TESTING centrally
OpenNCP QA and Release
MS adopt infrastructure for eID
MS deploy national infrastructure for eID
MS update local installation of NCP
MS perform Integration Test: NCP+eID
MS perform Regression Testing
PILOTING - Stage 3
16
4
18
25
4
4
29
4
32
34
36
38
2
2
2
2
40
2
42
44
46
2
2
15
37
4
39
48
47
42
46
50
51
52
53
6
2
1
4
4
1
1
1
18
F-15
M-15
A-15
M-15
J-15
J-15
A-15
S-15
O-15
N-15
D-15
Holidays
2
3
4
5
J-16
F-16
M-16
holidays
6
7
8
9
10
11 12 13
14
15 16 17
18
19 20 21 22
23
24 25 26
27 28 29 30
in
4.10
Understanding new BB specification and
implementation impact
Adding e-SENS: Trust Establishment (into CS)
Adding e-SENS: Configuration Services (into CS)
Refactor OpenNCP according to the new CS
Evolve the epSOS Central Services rationale
Architecture and Operation paradigm
(architecture and services) by adopting e-SENS
Building Blocks or BB features. This step will
have impact also at NCP level where
refactoring will need to be made in order to
allow the improved articulation model
between NCPs.
J-15
DURATION Weeks
31 32 33 34 35
36
37 38 39
40
41 42 43 44
45
46 47 48
49
50 51 52
53
54 55 56 57
58 59 60 61
62
63 64 65
66
67 68 69 70
va
l
DESCRIPTION
ap
pr
o
ACTIVITY
EC
Task ID
g
PLAN
Phase
Pe
nd
NOTE - The Domain Pilot Plan is a living document which should only be used digitally. Therefore, you can find it in the “e-SENS-WP5.2.1PilotPlanning_v1.3_20141212.xlsx” file uploaded in BSCW.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
103
Annex II: Requirements and Recommendations – checklist
Pe
nd
in
g
EC
ap
pr
o
va
l
(SOURCE: epSOS D3.8.2 Final National Pilot Set Up and Deployment Guide – Annex VI)
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
104
REQ
REQ
8
8.4
D3.6.2
D1.2.1; p. 51
X
X
X
X
X
X
X
X
X
X
5 Agreement on the evaluation process between NCP and pilot sites (type of
agreement not yet described)
6 Agreement with data processor should be signed.
REQ
8
8.2
D1.2.1; p. 43
X
X
X
X
X
REQ
5
REQ
REQ
7
6
5.2.1,
6.7
7.6
6.2.1.3
D3.8.2
D3.8.2
D3.8.2
X
X
X
X
X
X
X
X
X
REQ
5
5.2.1
D2.1.2
X
X
X
X
X
5
5
D2.1.2
X
X
X
X
REQ
va
l
ap
pr
o
EC
g
in
Pe
nd
7 All obligatory roles of NCP assigned
8 Change management must be in place (can be part of MS change
management)
9 Clinical aspects - Identification of terms - Define key terms such as Data
controller, Data Processor, Personal Data, Processing of personal data, Medical
Record or Health Record and so forth, according to the work done in D2.1.2
Legal and Regulatory Constraints on epSOS Design
10 Compare FWA with national legislation and discuss discrepancies with national
Data Protection Authority and NAB. Integrate localised FWA with national
rules.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
105
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Fulfilled (Y/N)
X
Check
Evaluation
X
NCP installation
X
NCP maintainance
X
NCP establishment
X
Marketing
D1.2.1; p. 44
Step
Server Room
8.2
SLA
8
FWA
REQ
Security
X
Consent
X
Semantics
X
PoC
X
NAB
X
SPOC
D3.8.2
Pilot Site
8.4
NCP-B
8
Central Services
REQ
Subject
NCP-A
Patient Summary
1 A local evaluation team and/or local evaluation manager is appointed for each
pilot site and NCP
2 A local instantiation of the overall evaluation model and evaluation plan needs
to be produced by the local evaluation team
3 Adjustment of local processes for epSOS patient consent.
4 Agreement between the epSOS evaluation team and local evaluation teams at
NCP and pilot site level (type of agreement not yet described)
No.
Original Deliverable
ePrescription/ eDispention
Topic
Section in Guidelines
Level
Main Chapter in Guidelines
Service
REQ* or REC**
Information text
X
X
X
X
REC
6.1.2.1,
7.4.1
6.1.2.1, 6.3
D3.8.2
X
X
X
REQ
6
7
6
D3.8.2
X
X
X
REQ
5
5.1.1.3
X
X
REQ
5
7
D3.8.2 D3.7.1 p.
25
D3.8.2 D3.7.1 p.
25
X
X
X
X
REQ
4
4.4.9
D3.8.2
19 epSOS System confidentiality level must be 100%.
REQ
6
6.2.1.4
REQ
6
6.2.1.4
D3.8.2 D3.7.1 p.
25
D3.8.2
in
nd
X
X
X
X
X
X
PoC
va
l
ap
pr
o
REQ
Pe
20 epSOS System integrity level must be 100%.
5.2.2,
7.3.1/2/3
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
106
Fulfilled (Y/N)
X
X
Check
Evaluation
X
NCP maintainance
D3.8.2
X
NCP installation
6.1.2.1
NCP establishment
6
X
Marketing
REC
X
Server Room
X
Step
SLA
X
FWA
X
Consent
X
Security
X
NAB
X
Semantics
SPOC
Pilot Site
D3.8.2
NCP-B
Patient Summary
6.1.2.1
Central Services
ePrescription/ eDispention
6
Subject
NCP-A
Original Deliverable
REQ
No.
g
11 Connection to national infrastructure, PoC preparation: Ensuring that
appropriate processes and procedures are in place (security measures,
safeguards etc.)
12 Connection to national infrastructure, PoC preparation: Appointing a liaison
person as link between PoC and NCP
13 Connection to national infrastructure, PoC preparation: Contact person
assigned by each pilot side
14 Connection to national infrastructure, PoC preparation: Defining and
implementing information security policy
15 Connection to national infrastructure, PoC preparation: FWA by HCPO and/or
HCP signed
16 Connection to national infrastructure, PoC preparation: HCP must be instructed
and trained
17 Describe National Infrastructure with the purpose of interfacing. Data sources,
Data Structures and Dataflow (eP, eD and PS) to the NCP (both as NCP-In-A-Box
and MS developed NCP)
18 Ensure that all equipment for the NCP is in place (insourced or outsourced)
EC
Topic
Section in Guidelines
Level
Main Chapter in Guidelines
Service
REQ* or REC**
Information text
6
6.2.1.4
D3.8.2
X
X
REQ
6
6.2.1.1
6.2.1.4
D 2.1.2 p. 29
X
6.1.3
D 2.1.2 p. 29
X
X
X
X
X
X
X
X
X
X
X
va
l
ap
pr
o
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
g
EC
SPOC
X
NCP-B
X
NCP-A
X
X
REC
6
X
X
REQ
5
5.2.4.2
D 3.6.1 p. 31
X
X
X
X
X
REQ
6
6.1.3
D3.8.2
X
X
X
X
X
Pe
29 Information about patient identification in country A must be available for
health care providers in country B
30 Information material for those groups who are relevant for the setup and
continuous service of the NCP (government, hospital owners, HCP
management)
31 Information to patients and health care providers about epSOS services must
be available on websites
32 Legal issues - national pharmaceutical legislation - Differences in national
pharmaceutical legislation can affect patient safety. This must be analysed and
addressed by the NCP organisation
X
X
X
X
X
5
5.2.3.1
X
X
X
X
X
REQ
5
X
X
X
X
REQ
5.2.4
D2.1.2 p. 35
D2.1.2
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
107
X
X
X
X
X
X
X
X
X
X
X
X
Fulfilled (Y/N)
REQ
X
X
Check
Evaluation
X
X
NCP maintainance
X
X
X
X
NCP installation
X
X
X
NCP establishment
D2.1.2
D3.8.2
D3.8.2
Marketing
5.1.1.1
6.2.1
6.2.1.2
X
Server Room
5
6
6
X
X
Step
SLA
REQ
REQ
REQ
X
X
X
FWA
X
X
Security
X
X
Consent
X
X
Semantics
X
X
PoC
Patient Summary
D3.8.2
D1.2.2
NAB
ePrescription/ eDispention
6.2.1.4
8.4
Topic
Pilot Site
Original Deliverable
6
8
Central Services
Section in Guidelines
REQ
REC
nd
21 epSOS System traceability level must be 100%.
22 Evaluation Contact Person should manage key-factors as identified by the
epSOS evaluation team
23 FWA must be localised
24 ICT maintenance organisation in place
25 Implementing operating processes: Rules for Problem management defined
and in use
26 Implementing operating processes: Rules for Service Level Management
defined and in use
27 Incident Management must be in place - A service desk must be in in place
with capability and mandate to handle incidents that may be technical,
organisational or practical, in order to restore services as described in 'Normal
service operation' defined as service operation within Service Level Agreement
(SLA) limits
28 Individual country information (in native language) on the epSOS website
in
Subject
Level
Main Chapter in Guidelines
No.
Service
REQ* or REC**
Information text
37 Marketing activities carried out: Marketing activities towards the general
practitioners
38 National legislation regarding patients consent for minors, patients with
dimished capacities and patients unable to give consent must be clarified. NCP
A is responsible for informing NCP B.
39 NCP-B must have a mandate from the national organisation to use the national
infrastructure for authentication and authorisation of HCPs
40 NCP-NAB contract must be signed (when NCP and NAB is not the same)
REC
7
D3.8.2
REQ
5
EC
REQ
6
REQ
5
X
X
X
X
X
X
X
X
D2.1.2
X
X
X
X
6.1.2.1
D2.1.2
X
X
X
X
X
X
5.1.1.3
D2.1.2
X
X
X
X
X
X
6
6.1.2.1
D3.8.2
X
X
X
X
X
X
X
7
6
7.2.4
6.1.2.1
D3.8.2
D3.8.2
X
X
X
X
X
X
X
7.3,
in
g
5.2.3
nd
REQ
Pe
41 Necessary changes, now and in the future, in the national infrastructure as a
result of supporting epSOS must be specified in agreements between epSOS
and the MS
42 Non disclosure agreements for system administrators must be in place
43 Organisational issues stemming from the NCP’s functional behavior - Future
changes in the national infrastructure are bound to occur. This must be taken
into account in the NCP: its connection to the national infrastructure should be
checked to see what the effect of local changes to the national infrastructure
is.
7.3.1
REQ
REC
X
va
l
ap
pr
o
X
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
108
X
SLA
X
X
X
FWA
NAB
X
X
X
Consent
PoC
X
X
Security
SPOC
Pilot Site
X
NCP-B
X
NCP-A
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Fulfilled (Y/N)
X
X
X
X
Check
Evaluation
D3.8.2
D3.8.2
D3.8.2
NCP maintainance
7.3
7.3.2
7.3
NCP installation
7
7
7
NCP establishment
REC
REC
REC
Marketing
34 Marketing activities carried out: Marketing activities towards hospitals
35 Marketing activities carried out: Marketing activities towards patient
36 Marketing activities carried out: Marketing activities towards pharmacies
Step
Server Room
D3.8.2
Topic
Semantics
7.4.2
Level
Central Services
7
Patient Summary
REQ
Subject
ePrescription/ eDispention
Section in Guidelines
33 Make sure that the necessary organisational connections between units in your
MS is in place (SPOC, Pilot-sites, PoC, HCP, HCPO, NAB i.e.)
No.
Original Deliverable
Main Chapter in Guidelines
Service
REQ* or REC**
Information text
8.3
D1.2.1
X
X
X
X
REQ
5
5.2.1, 5.2.3,
5.2.4
D2.1.2
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
va
l
ap
pr
o
EC
g
in
nd
5
5.2.3
D2.1.2
X
X
REQ
REQ
5
6
5.1.1.2
6.2.1.2
D2.1.2, D3.8.2
D3.8.2
X
X
X
X
Pe
REQ
X
X
X
X
REQ
D3.9.1
X
REQ
D3.9.1
X
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
109
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Fulfilled (Y/N)
8
X
Evaluation
REC
X
X
NCP maintainance
48 Piloting countries are recommended to assign a contact person nationally
responsible for the evaluation
49 Privacy aspects - patient consent - MS must define how patient consent for
data collection and data processing is interpreted in national legislation in the
localised FWA
50 Privacy aspects - prior patient consent - MS must define if a prior consent in
country of affiliation can be verified and documented
51 PSB must be informed about the changes in the localised FWA
52 Records are kept of all suspected or actual faults, and all preventive and
corrective maintenance.
53 Semantic Service - MS Terminology Responsible has approved the MTC before
using them in operation
54 Semantic Service - MS Terminology Responsible has been appointed and made
aware of his responsibilities and tasks
X
X
X
Check
X
X
X
NCP installation
X
NCP establishment
X
Marketing
X
X
Step
Server Room
X
X
SLA
D1.2.1
X
Consent
8.3
X
Security
8
NAB
REC
REQ
X
Semantics
D3.8.2
PoC
6.1.1
SPOC
6
Pilot Site
REQ
NCP-B
45 Organise needed staff for setting up NCP organisation, staff for operating the
NCP and for maintaining the NCP
46 Organise production of manuals for epSOS procedures at the different epSOS
sites.
47 Pilot Evaluation - contextualisation guidelines - Contextualised materials need
to be tested, preferably with representatives from targeted group and
feasibility of evaluation instruments in the context needs to be verified
Central Services
D3.8.2
NCP-A
7.4
Patient Summary
7
ePrescription/ eDispention
REQ
Subject
Original Deliverable
44 Organise and set-up the epSOS communication structure for the country
No.
FWA
Topic
Section in Guidelines
Level
Main Chapter in Guidelines
Service
REQ* or REC**
Information text
D3.9.1
REQ
D3.9.1
REQ
7
7.5
58 Semantic Services – Implementing the part of the MTC under the
specific MS responsibility: Assigning national certificate authorities for
respective parts of the catalogue
59 Semantic Services - Implementing the part of the MTC under the specific
MS responsibility: Translation and transcoding of the catalogue
REQ
7
7.5, 7.5.2
REQ
7
7.5, 7.5.1,
7.5.2
60 Semantic services – transcoding and Mapping - epSOS SW installation:
Adjustment of local processes for using patient (foreign visitors etc.)
information from pivot documents (PS, ePrescription, eDispensation)
61 Semantic services – transcoding and Mapping - epSOS SW installation:
Adjustment of local processes in order to provide data necessary to
complete pivot documents for patients (MS residents)
62 Setting up Information Security Management System and put it into
operation: SOA (Statement of applicability) definition and opertionality
REQ
7
REQ
63 Single Point of Contact assigned
Evaluation
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
D3.5.2
X
X
X
X
X
X
X
X
7.5.1
D.3.5.2
X
X
X
X
X
X
X
X
7
7.5.1
D3.5.2
X
X
X
X
X
X
X
X
REQ
6
6.2.1.6
D3.7.2
X
X
REQ
7
7.4.1
D3.8.2
X
X
EC
X
D3.5.2
g
nd
X
X
X
X
X
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
110
X
X
X
X
Fulfilled (Y/N)
Check
NCP maintainance
NCP installation
Marketing
NCP establishment
SLA
Server Room
FWA
Consent
Security
Semantics
PoC
NAB
va
l
SPOC
Pilot Site
NCP-B
Central Services
NCP-A
Patient Summary
Step
X
Pe
D3.5.2
Topic
ap
pr
o
REQ
Level
in
55 Semantic Service - SPOC has to verify epSOS specific Licence Agreements
are signed with the SDO, for the Coding Systems for which a Licence
Agreement does not exist
56 Semantic Service - SPOC has to verify if the MS has already signed
Licence Agreements with the SDO
57 Semantic Services - Implementing the part of the MTC under the specific
MS responsibility: Approving the process of the catalogue maintenance
ePrescription/ eDispention
Original Deliverable
Section in Guidelines
Subject
Main Chapter in Guidelines
No.
Service
REQ* or REC**
Information text
X
X
X
X
D1.2.1; p. 13
X
X
X
X
D1.2.1
X
D1.2.1, D4.4.2
X
PoC
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
in
g
EC
X
8.2
nd
8
Pe
REC
8
8
8.1
X
X
X
X
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
111
Fulfilled (Y/N)
D3.8.2
Check
Evaluation
6.6
NCP maintainance
6
NCP installation
X
X
NCP establishment
X
X
X
Marketing
X
X
X
Server Room
X
X
Step
SLA
7.2.3
6.2.1.4
FWA
X
Consent
X
Security
X
NAB
X
7
6
Deliverables
from WP3.13.10
D3.8.2
D3.8.2
REC
Semantics
X
SPOC
X
Pilot Site
X
Topic
va
l
REQ
X
NCP-B
71 The local evaluation plan should be consistent with the evaluation guidelines
described in ‘Pilot Project Initiation Document Template’ provided by WP4.2
HLDD D3.9.1
Central Services
REQ
4.2
NCP-A
69 The activity of the epSOS services shall be monitored at all relevant levels, i.e.
pilot sites, NCPs and flows of transaction between them
70 The local evaluation plan should address: How collecting, storing, aggregating
and sharing of data is organised, e.g. what data is automatically collected from
systems and how and by whom, how consent from participating citizens will be
verified, how local evaluators will be briefed or receive appropriate training,
what instruments and metrics are to be used
Patient Summary
REQ
ePrescription/ eDispention
REQ
REQ
4
ap
pr
o
66 System administrators training carried out
67 System availability level must be at least 95% per month, 7 days a week, from
7.00 am to 8.00 pm
68 Test of developed NCP/Interface components (i.e. National Connector) MUST
be performed according to epSOS test rules. This complies to component test,
system test, participating in Projectathon and field test. Descriptions in
Guidelines and epSOS document are available
Original Deliverable
REQ
Subject
Section in Guidelines
64 Specify and develop the function to transform MS documents into the epSOS
CDA (PDF), as input to NCP-In-A-Box (FET solution)
65 Synthesise Requirement Specification for your country from your descriptions,
epSOS Guidelines and epSOS deliverables (WP3.1 – WP3.10)
No.
Level
Main Chapter in Guidelines
Service
REQ* or REC**
Information text
REC
8
8.4
D1.2.1
X
X
X
X
X
X
REC
8
7
D3.8.2
X
X
X
X
X
X
PoC
va
l
ap
pr
o
X
X
X
X
X
X
X
X
nd
in
8.3, 7.3
Fulfilled (Y/N)
74 To support evaluation the epSOS evaluation team should provide a ‘help
function’ for the local evaluators
75 Translated material ready (e.g. a flyer) to explain the epSOS project, the
evaluation strategy and expected roles in MS
Check
Evaluation
X
X
NCP maintainance
X
NCP installation
X
X
NCP establishment
X
Marketing
D3.8.2
Step
Server Room
6.1.2.1
SLA
6
FWA
REQ
Consent
73 The organisation responsible for maintaining the NCP (and therefore partially
responsible for the circle of trust) must have the resources to carry out such
approvals (though this may not be relevant during the pilot phase)
Security
X
NAB
X
Semantics
X
SPOC
X
Pilot Site
D3.8.2
NCP-B
Patient Summary
6.1.2.1
Central Services
ePrescription/ eDispention
6
Subject
NCP-A
Original Deliverable
REQ
No.
g
72 The NCP must be connected to the national infrastructure: the NCP-A is to
provide patient information to other requesting NCPs in the circle of trust. To
this end, the NCP must have a mandate from the national organisation to
access the medical information of patients (role NCP-A)
EC
Topic
Section in Guidelines
Level
Main Chapter in Guidelines
Service
REQ* or REC**
Information text
Pe
NOTE - The checklist for requirements and recommendations is a living document which should only be used digitally. Therefore, you can find it in the
“Requirements and recommendations v0.15.xls” file uploaded in BSCW.
This list of steps needs to be reviewed according the e-SENS scope (e.g. legal and evaluation steps, are they applicable on e-SENS?).
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page
112
Annex III: Sequential Implementation Guidelines
(SOURCE: epSOS D3.8.2 Final National Pilot Set Up and Deployment Guide – Annex II)
The sequential implementation guidelines are to be used by the MSs in their implementation
procedures. This is only a sequential addition to the main checklist with requirements and
recommendations.
Recommended steps for Technical implementation:
Start
time
1
Understand epSOS business use cases
2
Understand epSOS architecture
3
Analyse NCP-In-A-Box for national use
4
Study epSOS Guidelines and epSOS Deliverables (WP3.1 WP3.10)
5
If the NCP-In-A-Box is to be used and a country is piloting as
country A, understand National Connector for NCP A in your
country
End
time
OK
Open
points
Remarks
EC
ap
pr
ov
al
ID
Carefully study National Interface and integrability with
National / Regional Infrastructure
If NCP-In-A-Box is to be used and a country is piloting as
country B, understand National Connector for NCP B in your
country
7
Understand Portal Adapter and portal for NCP B if used in
your country.
Pe
nd
in
g
6
Carefully study National Interface and integrability with
National / Regional Infrastructure.
8
If NCP-In-A-Box is used by a country piloting as country B
and if a portal is used, understand Portal Adapter (National
Interface) and portal for PoC interconnection.
9
Describe National Infrastructure with the purpose of
interfacing. Data sources, Data Structures and Dataflow (eP,
eD and PS) to the NCP (both as NCP-In-A-Box and MS
developed NCP)
10
If using FET common components (NCP in a box): Describe
the need for interfacing in your country.
11
If developing the NCP describe your needed components for
the NCP in your country
12
If using Portal in a country B: Describe how to use Portal to be
sure of all data are available.
13
Study Technical Security solution in your country according to
epSOS rules and set ups (see security checklist) and apply it.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 113
Specify and develop the function to transform MS documents
into the epSOS CDA (PDF), as input to NCP-In-A-Box (FET
solution).
16
Study and describe how your MS can use and comply with
the functions in Central Services
17
Synthesise Requirement Specification for your country from
your descriptions, epSOS Guidelines and epSOS
deliverables (WP3.1 – WP3.10)
18
If appropriate, use the Requirement Specification for design
and development, according to usual procedures in your
country. As part of the epSOS you can use all epSOS
documents
19
If NAB/authorities in your country decide to perform call it can
be Call for Information or Call for Tender (externally). In both
cases you must follow the legal rules in your country for the
calls. Use the Requirement Specification for your Call. You
can use all released epSOS document in calls.
20
Test of developed NCP/Interface components (i.e. National
Connector) MUST be performed according to epSOS test
rules. This complies to component test, system test,
participating in Projectathon and field test. Descriptions in
Guidelines and epSOS document are available
21
Start of Piloting is according to epSOS decisions.
al
15
ov
Study how you can fulfil the technical solution for epSOS
semantic service (perhaps perform a gap analysis) and apply
it.
g
EC
ap
pr
14
in
Recommended steps for understanding and
implementing legal aspects:
Appoint legal experts for epSOS-relationships in your country
23
Understand NCP from a legal point of view. Read 2.1.2. Study
Frame Work Agreement (FWA). Understand Clinical aspects
(Chapter 5.2). Understand National and European Rules
(Chapter 5.3). Understand the Liability structure (Chapter 5.4).
24
Localise FWA in your national language. Include national
legal and professional requirements in the localised version of
FWA.
25
Form combined agreements with Pilot-sites, PoC, NAB,
SPOC etc., according to FWA
26
Explain in English the localised agreements and the
agreement structure in your country.
27
Agreements in MS must be signed for creating the necessary
framework of the trusted domain (see signing of FWA in chap.
5.1.1.3). The signed agreements will be held locally in each
MS.
28
Set up the process and procedures to extend consent to
export patient data abroad.
29
Prepare the documents and the procedure to define the
consent document (in Country A language and all Country Bs
languages (or at least in English) to train HP-B
Pe
nd
22
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 114
31
Decide if the NCP organisation (or part of it) should be
outsourced in your country
32
Organise needed staff for setting up NCP organisation, staff
for operating the NCP and for maintaining the NCP
33
Make sure that the necessary organisational connections
between units in your MS is in place (SPOC, Pilot-sites, PoC,
HP, HPO, NAB i.e.)
34
Set-up Service Level Agreements (SLA) for the NCPorganisation and for operating NCP. Note the epSOS SLAlevel in chapter 6.2.1.4 Needed contracts with companies
running NCP or parts of it, if applicable.
35
Agreement with data processor should be signed.
36
Organise Service Desk for the NCP-organisation in MS. The
Service Desk should handle epSOS calls from other epSOS
countries as well as calls from epSOS Pilot-sites in the
country.
37
Make sure, that other Processes (ITIL), needed for operating
epSOS is in place in the country. (Chap. 6.2.1)
38
Insure that Technical, Organisational and Practical measures
comply to required Security standard for epSOS and that it is
documented.
ov
Decide if the national NCP organisation should be a
recognisable part of the national ICT organisation in the
country or it should be self-contained with necessary
cooperating with the national ICT organisation
in
g
EC
ap
pr
30
al
Recommended Organisational steps:
39
Pe
nd
Go thought the Security-checklist for making sure, that all
needed security is in place. (needed for auditing)
Prepare documents for Auditing security according to epSOS
security to be sent to PSB.
(MS should perform auditing themselves and declare
compatibility to epSOS standards
40
Appoint or contract skilled (certified) auditors.
41
Perform Security Auditing according to epSOS rules and time
schedule.
Recommended steps in implementing Practical Issues
42
Organise and set-up the epSOS communication structure for
the country. See chapter 7.4 in Guidelines.
43
Contact external partners in MS: Pilot sites, GPs Pharmacies,
Hospitals, relevant authorities and others as patient
associations, by sending epSOS information with invitation to
plenum meeting about epSOS. epSOS web-site should be
included in the information documents.
44
Perform one or two information meetings dependent of the
situation in the country.
45
Setting up the Master ValueSet Catalogue (MVC) and the
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 115
Master Translation/Transcoding Catalogue (MTC) is a major
task for the MS. epSOS cannot be running in a MS without
those catalogues. Staff must be appointed, trained and the
catalogue work started early in time.
If needed in the country, define and sign the Contract for
HealthTerm support
47
Make sure that all practicalities for running the NCP is in place
(read chapter 7.1.1). Refer to Organisational steps. Use the
“Requirement and Recommendations Checklist”
48
Organise production of manuals for epSOS procedures at the
different epSOS sites.
49
Ensure that all equipment for the NCP is in place (insourced
or outsourced)
50
Ensure that servers and server rooms are secure and
maintaining is sufficiently prepared
51
Training of staff must be planed and performed or contracted,
dependent of the situation in the country.
52
Non-disclosure agreements for system administrators must be
in place.
53
After primary information meetings the marketing activities is
needed in relation to the situation in MS. Public information
policy is important to make sure that the citizens and patients
are informed about epSOS - dependent of the situation in
your country.
g
EC
ap
pr
ov
al
46
Pe
nd
in
Define your Country citizens information procedures (through
institutional and or Media channels)
Define other Countries citizens information procedures
(through institutional and or Media channels)
Steps in implementing epSOS evaluation:
54
Appoint local evaluation teams for pilot sites and for the NCP
organisation (Managers for the teams should also be
appointed, - of course dependent of the situation in the
country).
Describe the evaluation in the MS to inform WP1.2.
55
Training of evaluation teams carried out by WP1.2.
56
The generic evaluation plan for the evaluation in MS should
be localised (depending of the service evaluated). See
chapter 8.2 in Guidelines
57
Contextualisation/adaption of the measurements tools should
be done as soon as the material has been released by the
Evolution Team in epSOS (WP 1.2)
58
The online tools built with the localisation and translation
feedback of the countries will be validated by the local
evaluation team.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 116
59
Baseline visit organised in cooperation with WP1.2 and
WP4.2.
60
Evaluation performed by WP1.2 together with the local (MS)
evaluation organisation according to rules from the epSOS
Evaluation Team, WP 1.2
Pe
nd
in
g
EC
ap
pr
ov
al
This list of steps needs to be reviewed according e-SENS scope (e.g. legal and evaluation steps, are
they applicable on e-SENS?).
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 117
Annex IV: eP/PS PN Pilot Readiness, Requirements, and
Recommendations Sheet
1. Platform Preparation
EC
ap
pr
ov
al
establish to be used version and content of MTC derived from common MVC
pre-load pilot environment with RTD and CTD (CDA-L3 and L1) of clinical value
publish RTD and CTD patient identifier and locators on BSCW
verify availability and maturity of to be used e-SENS BB's to support use case
verify and install validation mechanisms (XML Schema, Schematron, MIF, etc)
appoint SPOC for technical support of the pilot operation
prepare local translation of portals and NCP system facilities, if required
publish availability schedule for local NCP and services for piloting
establish bi-lateral legal agreement for foreign access on TM and values
make local TM services available for foreign translation through PA use case
restrict non-covered PN from accessing local TM services to avoid IPR issue
select and distribute to be used local eID carrier to immediate pilot partners
set-up bilateral legal foundation for excahnging test data, if so required
reconfirm usage rights on mandatory terminologies (epSOS license expired)
reconfirm test-data-only pilot approach -OR- establish FWA/CoT equivalent
g
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
M1
Pe
nd
in
2. Platform Installation or Update
collect e-SENS-tested and to be installed e-SENS BB and functional extensions
implement extensions and BB's with integration into local NCP ecosystem
register local eID carriers and outline any further requirements for access
establish HP authentication and login facilities if running as country B
deploy relevant eID hardware (card readers, certificates, etc) to pilot site
Pre-configure local eID (middleware, driver, trust stores, CRL/OCSP, etc.)
synchronize TM and LTR through TSAM or side load current MVC/MTC
separate e-SENS pilot environment from any production systems nearby
roll-out customer-facing facilities (portals, etc.) and publish access information
indicating baseline readiness of an technically operational NCP system
3. Platform Configuration
CG1
3.1
Wave 1 Conformance Gate: all PN's possess a stable baseline for participating in eSENS pilots
generate, load, and install security material (epSOS certificates)
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 118
pr
ov
al
configure security safeguards for baseline connectivity (VPN, TLS, IdP)
test baseline connectivity with all relevant partners and services
populate TSL w/ service endpoints and certificates according to NCP configuration
publish/exchange public portions of certificates with partners through TSL
publish/exchange relevant service endpoints with partners through TSL
pre-configure at least 1 test patient to accept foreign consent collection
set up a patient portal / home office demonstrator for PA UC pilots
configure baseline security policy on red flag and emergency access
deploy local adaptions (translations, consent template, information leaflets, etc.)
establish local role mapping policy to map HP's to correct role in IdA
make PIN available for use within patient consent workflow
set up Audit Trail and Audit Record Repository
apply still valid aspects of epSOS NCP BSP and epSOS IAR concerns to ecosystem
perform or reconfirm existing IAR of the pilot operation environment
PN regression testing to consolidate a stable basline NCP (MIILESTONE)
ap
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
M2
4. Pilot Operation
4.2
4.3
4.4
4.5
M3
EC
g
in
4.1
Wave 2 Conformance Gate: all PN's are ready to pilot the NEW e-SENS BB's and
adapted services
piloting and evaluation according to e-SENS KPI plan as well as PN-specific evaluation
criteria
refactor approved BB's into a format, documentation, and representation to be suitable
for external use
dissemination of new components to OpenNCP development group, potentially
FutureID, eHGI/eHN
dissemination of on-line evaluation and knowledge transfer to related activities, such
as EXPAND, eHGI/eHN
iteration of identified problems into 5.2 domain work for e-SENS addressing or external
deferral
Pilot Conclusion and consolidation of input material for CEF, etc. and PN evolution of
technology
Pe
nd
CG2
Assumptions
A1
A2
A3
A4
- no PN is piloting with real patients or identifiable patient data
- background knowledge and experience in typical IHE workflows and the epSOS ecosystem
in general is required
- this document targets the PN's specifically and does not fully addresses e-SENS 5.2 domain
activities
- since we have 4 well-established epSOS-operating PN's in the domain pilot, technical help
is extended by those
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 119
A5
A6
- relations to at least EXPAND and OpenNCP have been successfully established
- further activity is awarded to consolidating and aligning bilaterally with CEF
Risks, Mitigations
The scoping between e-SENS 5.2 eID and STORK 2.0 is established verbally but not
sufficiently documented. This needs to be done ASAP to avoid an inefficient overlap in
concerns. STORK is concentrating on the inclusion of authoritative eGov eID, while e-SENS
domain 5.2 builds on top of this infrastructure to integrate further domain-specific eID such
as health insurance cards.
The semantic provisions through e-SENS are not sufficient to propel a further evolution of
the eHealth domain's semantic requirements. It is likely that specific results will be yielded
and provided outside of e-SENS. Those may or may not be immediately addressed; however
e-SENS internally does not possess the resources to actively monitor those developments.
R5
Pe
nd
R4
in
g
R3
EC
ap
pr
R2
ov
al
R1
No PN has currently recorded the need or willingness to pilot identifiable patient data or to
authorize the operation of the e-SENS pilot in a production environment. Consequently, eSENS is running the risk of producing results of uncertain value with the demonstrations
already done by STORK 2.0. A possible mitigation is either a very high technical bar as
discriminator for its technical value or to appoint two pilot partners with existing legal
relations to elevate to real patients and data.
e-SENS itself does not possess the resources to facilitate establishing a non-pilot legal
environment to elevate pilots and its technology into routine operation within the common
market. PN's are requested to invest individually to propel a specific use case, which leads to
heavy re-use of existing infrastructures with all benefits and downsides. This impacts the
identification and extraction of KPI and real-world results. While PN seek the advancement
of their local services, the EC is seeking consolidated input towards CEF, etc. with little to no
overlap between the two approaches.
Several critical provisions of the epSOS project, such as the legal foundation of a crossborder data exchange, royalty-free access to terminology licenses, and the central
providence of configuration means have ceased to exist. All PN must check a priori whether
a continued operation of their epSOS ecosystem is legitimate at the current point in time.
Red points: Legal requirements built by epSOS
Bold points: Very important
Orange points: Check points
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 120
Part II:
ov
al
UC 5.2.2 eConfirmation
Pe
nd
in
g
EC
ap
pr
Domain and National Pilot Plans
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 121
8. Domain Pilot Plan of Use Case 5.2.2: eConfirmation
8.1.
Use Case Overview
Pe
nd
in
g
EC
ap
pr
ov
al
This use case describes how a Health care provider (HCP) in a MS (MS-B) is able to obtain a
Provisional replacement certificate, being an electronic insurance confirmation and serving as a
payment guarantee for a patient who is insured with a Health insurance organisation in another MS
(MS-A). The use case takes place in the context of a patient on a temporary stay abroad, who is in
need of medical treatment, and is not able to present a document indicating his entitlement to
benefits in kind (Regulation 987/2009 article 25).
Figure 27: Use Case Diagram
The Institution of the place of stay contacts, upon request, the Competent institution in MS-A. The
Health insurance organisation (HIO) where the patient is insured is the competent institution in this
use case. The Health insurance organisation will issue the Provisional replacement certificate.
The request received by the Institution of the place of stay is submitted from the health care
provider, and is send with the affirmative consent of the patient.
The Provisional replacement certificate can be obtained using key attributes from documents such as
passports, drivers’ license, or national or corporate insurance health cards. The patient is used to
using these documents in his/her home country to obtain electronic evidence of entitlement. Some
insurance health cards are smart cards and might be read electronically.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 122
8.2.
8.2.1.
Motivation and Goals
Background and rationale
The service provides citizens of the MS access to necessary healthcare during a temporary stay in any
of the 28 EU countries and in Iceland, Lichtenstein, Norway and Switzerland, under the same
conditions and at the same cost (free in some countries) as people insured in that country.
When an insured person is not able to present a document indicating his/her entitlement to benefits
in kind, the service provides a way to request and obtain an electronic Provisional replacement
certificate (ePRC). The ePRC, issued by the Health insurance organisation where the patient is
insured, provides evidence of entitlement similar to the current paper based Provisional replacement
certificate, but without the costs of manual procedures.
Value and Domain importance
ap
8.2.2.
pr
ov
al
Persons often do not have a European health insurance card with them in case of necessary medical
treatment abroad, and frequently have to pay the costs out of pocket. Cash payments are expensive
because it results in paper work to reimburse the insured person, and often causes disputes in case
of differences between private and public prices.
EC
The service enables citizens to demonstrate entitlement to benefits in kind in a fellow MS according
to the EU Regulation 883/200413 and Regulation 987/200914.
in
g
The service enables health care providers to obtain a Provisional replacement certificate in real time,
and verifies if a patient from a fellow MS is entitled to benefits. The service provides an easy way of
making sure that the treatment will be paid. The Health care provider might decide to integrate the
service into his information system or use a generic portal. In case of the entitlement, the Health care
provider uses familiar national procedures for invoice settlement.
Pe
nd
The service adds value to the services provided by the competent institutions, enables electronic
invoicing and contributes to substantial administrative cost savings.
8.2.3.
Specific relationship with prior LSPs or other domain
initiatives
The service is a redesign based on the results of the NETC@RDS project and ENED network. Basically
the service provided to EU citizens did not change substantially. However in comparison to
NETC@RDS/ENED the architecture has completely been redesigned. The architecture now is based
on the e-SENS 4-corner model and the architectural implementation takes into account the various
legal roles of the actors involved. A corner 1 ‘connector’ has been introduced to distinguish explicitly
the legal responsibilities of the Competent Institutions in both MS A and B. Moreover three e-SENS
13
Regulation (EC) No 883/2004 of the European Parliament and of the Council of 29 April 2004 on the
coordination
of
social
security
systems,
http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0001:0123:en:PDF
14
Regulation (EC) No 987/2009 of the European Parliament and of the Council of 16 September 2009 laying
down the procedure for implementing Regulation (EC) No 883/2004 on the coordination of social security
systems http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:284:0001:0042:en:PDF
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 123
BBs are being applied in the new architecture. As result of a positive insurance verification, the
eConfirmation service provides an ePRC that is to be considered as an electronic document according
to the eIDAS definition (Regulation 910/201415).
8.3.
Process Description
8.3.1.
Actors
The following actors take part in the use case:
Description
Healthcare provider
A person or organisation to work in any field of physical or mental
health. Within the context of this use case, the person can also be
an administrative clerk.
Institution of the place of stay
The institution of the place of stay is the institution, which is
competent to provide benefits in the place where the patient is
staying. These benefits are provided on behalf of the Competent
institution in MS-A (the Health insurance organisation), in
accordance with the provisions of the legislation it applies (see
article 19 of Regulation 883/200416).
Health insurance organisation
An organisation that offers health insurance, an insurance to cover
the cost of medical care. The health insurance organisation is the
institution with which the patient concerned is insured at the time
of the application for benefit, or indicates that he/she is insured
with.
Competent Institution means:
Pe
nd
Competent institution in MSA
in
g
EC
ap
pr
ov
al
Actor
(i) the institution (MS A) with which the person concerned is
insured at the time of the application for benefit; or
(ii) the institution (MS B) from which the person concerned is or
would be entitled to benefits if he or a member or members of his
family resided in the Member State in which the institution is
situated; or
(iii) the institution designated by the competent authority of the
Member State concerned. (see article 1q – definitions – of
Regulation 883/2004)
15
Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic
identification and trust services for electronic transactions in the internal market and repealing Directive
1999/93/EC http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014R0910&from=EN
16
Regulation (EC) No 883/2004 of the European Parliament and of the Council of 29 April 2004 on the
coordination
of
social
security
systems,
http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2004:166:0001:0123:en:PDF
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 124
8.3.2.
Preconditions
The following conditions must be met before the use case can start.
1. A healthcare provider must be able to submit a request from a computer system. This might
be an information system of the health care provider. Alternatively, the Institution of the
place of stay could provide a generic portal.
2. The institution of the place of stay provides the service obtaining a Provisional replacement
certificate and is responsible for the terms and conditions of granting access to the service.
3. Health insurance organisations must have a service available for issuing a Provisional
replacement certificate.
al
4. The healthcare provider has positively identified the patient.
ov
5. The patient has informed the Health care provider about the competent MS (where he/she is
insured) and is able to present a document that holds the key attributes to the health
insurance policy.
8.3.3.
Flow of events
EC
ap
pr
6. The healthcare provider must have the patient’s consent when submitting the request.
Submitting the request means that the Health care provider confirms that the patient has
given his/her permission to request a Provisional replacement certificate on his/her behalf
and to retrieve his/her relevant personal data.
Pe
nd
in
g
The process flow is part of the intake process of a patient, which starts when a Health care provider
receives a request for medical assistance from a patient who is on a temporary stay in a MS-B. The
patient is not able to present a document issued by the competent institution indicating his
entitlement to benefits in kind. If the insured person does not have such a document, the Institution
of the place of stay, upon request or if otherwise necessary, shall contact the Competent institution
in order to obtain one (regulation 987/2009 article 25-1).
The use case starts when a Health care provider submits a request to obtain a Provisional
replacement certificate. MS may have their own standards and definitions for documents, so the
request may be in a local format.
1. The Institution of the place of stay in MS-B receives the request.
2. The Institution of the place of stay produces a document to request a Provisional
replacement certificate using the guidelines provided by the Competent institution in MS-A.
3. The Institution of the place of stay sends the request to the Health insurance organisation,
being the Competent institution in MS-A where the patient is insured and logs the request as
being send with a date and time stamp.
4. The Health insurance organisation receives the request and logs the request as received with
a date and time stamp.
5. The Health insurance organisation verifies if the patient is actually insured.
6. The Health insurance organisation issues an electronic Provisional replacement certificate
and seals the document to provide proof of origin and integrity.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 125
(If the patient is not insured then the Health insurance organisation will respond that the
patient is not insured or not known)
7. The Health insurance organisation sends the Provisional replacement certificate to the
Institution of the place of stay in MS-B and logs the Provisional replacement certificate as
being sent with a date and time stamp.
8. The Institution of the place of stay receives the Provisional replacement certificate and logs it
as received with a date and time stamp.
9. The Institution of the place of stay verifies origin and integrity of the Provisional replacement
certificate and logs the outcome of the verification with a date and time stamp.
Post-conditions
ov
8.3.4.
al
10. The Institution of the place of stay sends the information received to the health care
provider.
8.3.5.
ap
pr
If the validity of an actual health insurance policy is confirmed then the healthcare provider has
obtained a Provisional replacement certificate. If the validity of the insurance policy is not confirmed
then the Health care provider is informed.
Assumptions
EC
The electronic Provisional replacement certificate (meeting the requirement in regulation 910/2014),
is assumed to be accepted as a valid document by the institutions involved in the invoice clearing
process (Competent institutions, Institution of the place of stay, and Liaison Bodies in the MS).
Pe
nd
in
g
A governance structure (agreed upon in a General Agreement) is assumed to be in place. A
governance committee reviews, agrees, and monitors the terms, conditions and policies to
participate in the eConfirmation community and to connect to the eConfirmation solution. Every
participant agrees to comply with these terms, conditions and policies, which also include privacy
and end-to-end safety- and security policies.
The logs of the documents send and received will be used as evidence in case of disputes. Every
participant needs to agree on this and will trust other participants in the correctness of their logs.
8.3.6.
Special requirements
The following special requirements need to be addressed during design or implementation:
1. The National health fund (NFZ) in Poland requires Polish patients to sign a form so that the
patient guarantees the payment of costs in case the patient is not insured (due to time delay
in update of NFZ data).
2. The Provisional replacement certificate has a limited period of validity. The request must
contain a period of validity, which can be used to decide about the period of validity for the
Provisional replacement certificate. The Health insurance organisation decides about the
issued period of validity.
3. The data provided with the electronic Provisional replacement certificate must enable
further automatic processing and/or electronic invoicing.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 126
4. The service must comply with the applicable requirements in Regulation 883/2004 on the
coordination of social security systems and on Regulation 987/2009, which is laying down the
procedure for implementing Regulation 883/2004.
5. The service must comply with the applicable requirements in regulation 910/2014 on
electronic identification and trust services for electronic transactions in the internal market
repealing Directive 1999/93/EC.
6. Regulation 910/2014, whereas statement 59, states that documents need to be sealed using
a (advanced) seal from a qualified certificate issued by a qualified trust service provider (see
annex III of the regulation for the requirements for qualified certificates for electronic seals).
al
7. The clocks of computers used creating or updating the date and time stamp of the log need
to be synchronized over a network to a common time base.
ov
8. The service must provide the response within a reasonable timeframe (seconds) after the
request is submitted.
8.4.1.
Architecture and use of Building Blocks
Overview of the solution
EC
8.4.
ap
pr
The rational for this requirement is that the Health care provider wants to minimalize the
time needed for the intake of the patient, including obtaining the Provisional replacement
certificate.
The figure below gives an overview of the eConfirmation solution.
Pe
nd
in
g
The Institution of the place of stay is going to provide a service to request and obtain a Provisional
replacement certificate for a patient. The Health care provider uses the service in the process of
intake (or also named the admission or registration process).
The Institution of the place of stay may choose to implement the service with a web portal, a web
service, or both.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 127
al
ov
pr
ap
EC
Figure 28: Overview of the eConfirmation solution
Pe
nd
in
g
The architecture of the solution is a four corners model. The four corners are arranged as follows:
MS-B connector (corner 1) as the producer of a request document, MS-B gateway (corner 2) as the
sending gateway, MS-A gateway (corner 3) as the receiving gateway, and the MS-A connector (corner
4) as the consumer of the request. Vice versa, the MS-A connector will be the producer of the
Provisional replacement certificate.
The four corners model enables the competent institutions to choose for different operating
scenarios. The Institution of the place of stay or the Health insurance organisation might choose a
(commercial) gateway but keep responsibility of the connector, or choose to have the connector
operated by a service provider. The connectors are responsible for producing and consuming the
documents, and the gateways for the transportation of the documents. The Institution of the place
of stay is accountable for the solution (both connector and gateway) in MS-B, as is the health
insurance organisation accountable for the solution (both connector and gateway) in MS-A.
8.4.2.
Application components and their functions
This paragraph describes the functions of the solution to realize the use case scenario. Every function
is assigned to an application component.
8.4.2.1. Step 1: MS-B creates and submits a request document
The healthcare provider submits a request to obtain a Provisional replacement certificate for the
patient. The request contains all data required by the Institution of the place of stay.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 128
al
ov
pr
ap
EC
g
Figure 29: Create and deliver eConfirmation request
in
The request is received by the MS-B connector implemented by the Institution of the place of stay
and is received under the terms and conditions of the Institution of the place of stay.
Pe
nd
The connector reads the request and produces a request document to obtain a Provisional
replacement certificate in MS-A. The document is packaged and routed to the connector of MS-A
(corner 4) using a document routing envelope for delivery. The connector sends the envelope, which
contains the document, to the gateway and logs the date and time of sending the request document.
The gateway is responsible for the transportation of the envelope and the document to MS-A.
8.4.2.2. Step 2: MS-A receives and processes the request document
The second process starts when the request document is delivered to the MS-A gateway. The
request must be received from an authenticated and trusted gateway.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 129
al
ov
pr
ap
EC
in
g
Figure 30: Receive and process eConfirmation request
Pe
nd
The gateway receives the transport of the document and sends it to the MS-A connector. The
connector receives the document, unpacks it, and validates the request. The request must meet the
requirements of the Competent institution in MS-A, being the Health insurance organisation.
The connector verifies the entitlement to benefits in kind for the patient that requested the
Provisional replacement certificate. The connector uses a service provided by the Health insurance
organisation to verify the health insurance status of the patient. The verification results in a
confirmation of the entitlement to benefits in kind, or a denial because the patient is not insured or
not known.
The connector uses the confirmation (or denial) to produce a document. If the entitlement is
confirmed, then the connector produces a Provisional replacement certificate. The document
produced is sealed using a qualified certificate. The seal is an advanced seal, defined in XML
Advanced Electronic Signatures (XAdES) with a basic profile.
The sealed document is packaged and routed to the connector of MS-B (corner 1) using a document
routing envelope for delivery. The connector sends the envelope and the document to the gateway
and logs the date and time of sending the document.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 130
al
ov
pr
ap
Figure 31: Provisioning of the Provisional replacement certificate
The gateway is responsible for the transportation of the envelope with the document to MS-B.
EC
8.4.2.3.Step 3: MS-B receives the response document
Pe
nd
in
g
The third process starts when the MS-B gateway receives the response document. The response
document is a Provisional replacement certificate, which proofs the entitlement to benefits in kind
for the patient, or is a document that denies the health insurance coverage for the patient. The
document must be received from an authenticated and trusted gateway in MS-A. The gateway sends
the document to the connector.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 131
al
ov
pr
ap
EC
Figure 32: Receive provisional requirement certificate
8.4.3.
Pe
nd
in
g
The connector receives the document, unpacks it, and verifies the seal to proof origin and integrity of
the document. When verified, the connector provides the document to the Health care provider (on
the benefit of the patient) using local standards and definitions.
eConfirmation document exchange
The document exchange is defined in a service contract between the connectors. The service
contract will describe the format for the request and the response documents and the business rules
to apply.
The documents use the reference model as shown below.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 132
al
ov
pr
ap
EC
Figure 33: Reference model
The character set used for the request and response will be UTF-8.
g
8.4.3.1. Request document
in
The request consists of a common list of attributes used by every MS and a MS specific part.
Pe
nd
Per MS, the mandatory attribute values need to be filled in.
Mandatory attributes per MS
National citizen identification number
Documents that holds the key attributes
Passport
National
identity
document
Driver’s
license
National (or
corporate) health
insurance card
NL, PL, SK,
EE
NL, PL, SK,
EE
NL, EE
AT17
Document serial number
AT
Birth date
NL, SK, EE
NL, SK, EE
NL, EE
AT
Family name
SK, PL, EE
SK, PL, EE
EE
AT
Given name
SK, PL, EE
SK, PL, EE
EE
AT
17
NHIC is in the Austrian case to be understood as the "e-card". In case the data from the "e-card" are captured
manually, the insurance identification number, the name and the first name have to be captured.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 133
Identity of the Health insurance
organisation
SK
SK
Expiry date of document
EE
EE
AT
EE
AT
(Passports and National identity document are only applicable if the patient is insured in the MS of his/her nationality)
8.4.3.2.Provisional replacement certificate
al
Every request needs a unique identifier (UUID) to be able to trace the request back to the
organisation that requested the information. The trace is needed in order to comply with privacy
laws and in case of disputes. The request identifier is created by the requesting organisation and
persisted by the Health insurance organisation responding to the request. The request needs to
contain a requested period of validity.
ov
The Provisional replacement certificate consists of the attributes defined in the table underneath.
Attribute
Remarks
Person
Birth date
Person
Family name
Person
Given name
Person
Insurance status
Citizen
National citizen
identification number
Status answered is “Insured”.
AT, NL, SK,
EE
AT, SK, EE
All
NL, PL, SK, EE
in
Pe
nd
Is returned
by MS
AT, SK, EE
g
EC
ap
pr
Entity
Health insurance
organisation
Residential country of the
Health insurance
organisation
ISO code of the country
All
Health insurance
organisation
Identification of the Health
insurance organisation
The identity of the Health
insurance organisation needs to
be a unique and common
identifier in the country of the
Health insurance organisation.
All
Insurance Policy
Insurance identification
number
Unique identifier of the
insurance policy of the patient
for the Health insurance
organisation.
AT
Provisional
replacement
certificate
Document serial number
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 134
Entity
Attribute
Remarks
Is returned
by MS
Provisional
replacement
certificate
Valid date from
All
Provisional
replacement
certificate
Valid date through
All
ov
al
Reference information to relate the Provisional replace certificate with the original request must
exist. The Provisional replacement certificate will be provided as an xml document and as a pdf
document.
8.4.3.3. Document for denial insurance coverage
ap
pr
The document for the denial of insurance coverage consists of the attributes defined in the table
underneath.
Remarks
Is returned
by MS
Person
Insurance status
Status answered is “No” or
“Unknown” when the patient is
not found.
All
Health insurance
organisation
Residential country of the
Health insurance
organisation
ISO code of the country
All
Identification of the Health
insurance organisation
The identity of the Health
insurance organisation needs to
be a unique and common
identifier in the country of the
Health insurance organisation.
All
in
Pe
nd
Health insurance
organisation
EC
Attribute
g
Entity
Reference information to relate the document for denial with the original request must exist.
8.4.4.
Use of e-SENS BBs per area
The solution will apply and pilot three architectural BBs: eDelivery, eDocuments, and eSignature. The
eDelivery building block finally will handle the transportation of the documents. The eDocuments
building block is used for the provisioning of the documents, and the packaging of the documents.
The eSignature will be used to seal the document and to validate the seal.
Every BB will be profiled to the needs and requirements of eConfirmation.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 135
8.4.4.1. eDelivery
ap
pr
ov
al
The eConfirmation solution uses the e-SENS Message Exchange Protocol as an Architectural Building
Block, which is realized as a profile of the ebMS3 and AS4 OASIS Standards. It has provisions for use
in four-corner topologies, but can also be used in point-to-point exchanges.
Figure 34: Message exchange between the corners
in
g
EC
The message exchange protocol between the gateways will be a one-way push. This protocol must
ensure a high performance. All communication between the gateways will be asynchronous. The way
to integrate the backend of the gateway, with the connectors, is to be defined by the competent
institutions in MS-A and MS-B, with the constraint that a push message exchange pattern is
mandatory.
Pe
nd
Security
The messages will be secured using a transport seal and encryption. The gateways will be identified
using certificates.
Since the gateway will act both as a sender and a receiver, both a trust store and a key store are
needed. The difference between a key and a trust store is that the key store contains the certificate
information of the server itself and the trust store contains the certificate information related to the
servers the MSH (Message Service Handler) should trust. A trust store contains the chain of
certificates of those servers and in some cases including the certificates of those servers themselves.
Both the key store, as well as the trust store is password protected.
Processing modes
The MSH of the gateway is responsible for creating the ebMS3 SOAP messages. The document
producer should only deliver the payload of the message. Per MSH there will be one or more
processing modes (P-Mode). The processing modes are basically a set of configuration parameters. It
contains the contextual information that governs the processing of a particular message. Think of the
URL of the endpoint, certificate information etc. The gateway reads the document routing envelope
and sets the processing mode mapped to the information in the envelope.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 136
al
ov
pr
Figure 35: MSH / P-Mode configuration
ap
Processing modes are needed for the request and the response documents. Every MS-B must
configure a processing mode for the transportation of the request to the gateways of all MS-A, and
vice versa MS-A must configure processing modes for the transportation of the response to the
gateways of all MS-B.
EC
8.4.4.2.eDocuments
in
g
The eConfirmation solution has defined three documents. These documents are described through a
structured metadata document, which will be available for everyone who produces or consumes a
document. The vocabulary for describing the documents is yet to be defined.
Pe
nd
Every document produced will be packaged using Associated Signature Containers (ASiC) with the
extended container type. The extended container can contain multiple data objects.
The package is to be embedded in a document routing envelope. The standard used for the
document routing envelope is UN/CEFACT Business Document Header (SBDH). SBDH is interpreted
by the gateway for routing the document to the gateway of MS-A. SBDH enables the connectors to
route the document on a semantic level while the gateways route on a technical level.
The SBDH includes information on the sender and receiver, document identification, and the process
(see XML outline below).
<?xml version="1.0" encoding="UTF-8"?>
<sh:StandardBusinessDocumentHeader xmlns:sh=
"http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
<sh:HeaderVersion>
The version number of the header must be set is 1.0
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 137
<sh:Sender>
<sh:Identifier Authority="">
<sh:ContactInformation>
<sh:Contact>
<sh:EmailAddress>
<sh:FaxNumber>
<sh:TelephoneNumber>
<sh:ContactTypeIdentifier>
</sh:ContactInformation>
</sh:Sender>
The identifier authority for the sender is specified using
ebCore Party Id.
The contact information should contain information of the
person to contact from the sender. The sender is the
Institution of the place of stay or the Health insurance
organisation.
<sh:Receiver>
<sh:Identifier Authority="">
</sh:Receiver>
The identifier authority for the receiver is specified using
ebCore Party Id.
<sh:DocumentIdentification>
<sh:Standard>
<sh:TypeVersion>
<sh:InstanceIdentifier>
<sh:Type>
<sh:CreationDateAndTime>
</sh:DocumentIdentification>
ov
al
@TBD
ap
The manifest describes the attachment, which is the
document included.
in
g
EC
<sh:Manifest>
<sh:NumberOfItems>
<sh:ManifestItem>
<sh:MimeTypeQualifierCode>
<sh:UniformResourceIdentifier>
<sh:Description>>
<sh:LanguageCode>
</sh:ManifestItem>
</sh:Manifest>
pr
The value of the type element must be set to PRCRequest,
PRC, or PRCRejection
Pe
nd
<sh:BusinessScope>
<sh:Scope>
<sh:Type>
<sh:InstanceIdentifier>
<sh:Identifier>
<sh:BusinessService>
<sh:BusinessServiceName>
<sh:ServiceTransaction
TypeOfServiceTransaction=""
IsAuthenticationRequired="true"
IsNonRepudiationRequired="false"
IsNonRepudiationOfReceiptRequired="false"
IsIntelligibleCheckRequired="true"
IsApplicationErrorResponseRequested="true"
TimeToAcknowledgeReceipt="P5S"
TimeToAcknowledgeAcceptance="P5S"
TimeToPerform="P5S" Recurrence="3"/>
</sh:BusinessService>
</sh:Scope>
</sh:BusinessScope>
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 138
Identification of the sender and receiver
The Institution of the place of stay and the Health insurance organisation must be named in the EESSI
Public Directory of European Social Security Institutions.
Authority=“urn:oasis:names:tc:ebcore:partyid-type:unregistered:eessi:publicdirectory”
@TBD
8.4.4.3.eSignature
al
For the creation and validation of seals, XML Advanced Electronic Signatures (XAdES) will be used.
XAdES extends the IETF/W3CXML-Signature Syntax and processing specification (XMLDSig). XAdES
defines six profiles differing in protection level. eConfirmation will use the XAdES Basic Electronic
Signature profile (XAdES-BES).
pr
ov
The XAdES-BES profile provides basic authentication, integrity protection, and satisfies the legal
requirements for advanced electronic signatures as defined in the directive 1999/93/EC18. The profile
does not provide non-repudiation of its existence. Non-repudiation in case of disputes will be subject
of the terms and conditions in the General Agreement (GA) between the competent institutions.
EC
ap
Only the documents produced by the health insurance organisation will be sealed electronically to
guarantee origin and integrity of these documents. The integrity means that the document has not
changed since it has been issued by the health insurance organisation in MS-A. To provide proof of
origin and integrity, the electronic seal needs to be an advanced seal (in terms of regulation
910/2014 (eIDAS)) based on a qualified certificate.
Use of established infrastructure at EU and MS level
Pe
nd
8.4.5.
in
g
The verification of the seal during the pilot will be based on the exchange of public keys between the
Health insurance organisations (that seals the document) and the Institution of the place of stay (that
validates the seal).
For cross-border communication an infrastructure needs to be established. EESSI might be useful as
an infrastructure in future. For the time being the MSs will use existing local infrastructures for the
communication between health care providers and the central gateway to the eConfirmation service
in a MS.
8.4.5.1. From prior LSPs
The eConfirmation service is based on the previous NETC@RDS (continued by ENED) and Ten4Health
(eTEN funded) projects.
8.4.5.2. Other
Bilateral projects are running in cross-border regions, based on planned care. Both eConfirmation
and eBilling (solutions providing services alike) are already being applied in daily routine.
18
Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community
framework
for
electronic
signatures,
http://eur-lex.europa.eu/legalcontent/EN/TXT/PDF/?uri=CELEX:31999L0093&from=EN
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 139
8.5.
MS relevance
The domain use case is relevant for all MSs. The following MSs are participating in the pilot: Austria,
Estonia, Netherlands and Poland. Moreover Greece and Slovakia have expressed their interest. The
Czech Republic has withdrawn as piloting MS.
8.6.
Pilot Planning: Phases, Activities, Milestones,
Dependencies
8.6.1.
Detailed design of pilot
al
The partners intending to pilot the eConfirmation service need to agree upon the solution
architecture of the service. The solution architecture includes the final decision of the applicability of
the building blocks defined in WP6.
Pe
nd
in
g
EC
ap
pr
ov
The strong dependency with WP6 is a risk for the progress of the pilot. Alignment is taking place with
WP6.
Milestone achieved: February 2015
8.6.2.
Technical Implementation
Each partner, intending to pilot iterates to a potentially consumable solution. This means that the
solution has enough features to be deployable.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 140
Milestone achieved: Q2 2015 (under reservation of availability of sufficient technical resources and
project management)
8.6.3.
Readiness Testing and Conformance
The solution of a participating MS is ready for deployment. Different conformance gates are being
defined on readiness for the legal, semantic, organisational, and technical aspects of the solution.
Participating MS are allowed to join the project and the project test environment. Before going
operational however, every participating partner must agree to the General Agreement (GA) and the
measures on security, privacy protection, performance, and governance structure.
Milestone achieved: Q3 2015 (Depending on the precondition under the previous section)
Launching and Running
Pe
nd
in
g
EC
ap
pr
ov
The solution is going live.
al
8.6.4.
Milestone achieved: Q3 2015 (Depending on the precondition under the previous section)
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 141
9. National Pilot Plan of Estonia for UC 5.2.2
9.1.
Pilot scope
9.1.1.
Domain use case to be piloted
Estonian citizens are entitled to benefits in kind in a fellow Member state according to Regulation
883/2004, but only if they are able to present a document indicating their entitlement. The
competent institution issues this document, the European health insurance card (EHIC).
pr
ov
al
If the person does not have such a document, he/she can request the Institution of the place of stay
to contact the competent institution in order to obtain a Certificate provisionally replacing the
European health insurance card (PRC). The competent institution in MS A is most probably the
institution where the person is insured, but there are exceptions (e.g. border workers). The
Competent institution is defined in article 1 of Regulation 883/2004.
ap
All actors involved (insured persons; Institution of the place of stay, health care providers, and
competent institutions) in the current EHIC process face many disadvantages in terms of customer
friendliness, usability, efficiency, cost effectiveness, throughput times and quality of data.
EC
The eConfirmation service has the following advantages:
A better experience for insured persons because they can use the documents they are used
to use in Estonia, such as passport or driver‘s license.

Insured persons will have no stress demonstrating their entitlement.

Insured persons will not experience the risk of partially reimbursement (legal versus private
tariffs).

Risk of fraud or misuse of cards is mitigated.

Decrease of administrative handling costs, and optimized processes, for all actors involved in
the cross border health care provisioning.

No costs for applying, processing, producing and issuing EHIC's (recurring costs).

Improving quality of administrative data.
Pe
nd
in
g

Estonian partners are aiming to demonstrate that e-Confirmation provides a state of the art, and cost
effective alternative for the current EHIC and PRC procedures.
9.1.2.
Business process overview
This use case describes how a Health care provider (HCP) in a member state (MS-B) is able to obtain a
Provisional replacement certificate, being an electronic insurance confirmation and serving as a
payment guarantee for a person who is insured with a Competent institution in another member
state (MS-A). The use case takes place in the context of a person on a temporary stay who is in need
of medical treatment, and is not able to present a document indicating his entitlement to benefits in
kind (Regulation 987/2009 article 25).
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 142
The Institution of the place of stay contacts, upon request, the competent institution in MS-A. The
competent institution will issue the Provisional replacement certificate. The request received by the
Institution of the place of stay is submitted by the health care provider, and is sent with the
affirmative consent of the person.
The Provisional replacement certificate can be obtained using key attributes from documents such as
passports, driver’s license, or national or corporate insurance health cards. A person is familiar with
using these documents in his/her home country to obtain electronic evidence of entitlement. Some
insurance health cards are smart cards and might be read electronically.
9.1.3.
Estonian pilot participants and stakeholders
Pe
nd
in
g
EC
ap
pr
ov
al
Pilot participants in Estonia are:
 Estonian Health Insurance Fund (Haigekassa) manages all citizen insurance information in
Estonia. It develops and operates a communication infrastructure to communicate messages
between health care providers and health insurance organizations in Estonia. Estonian Health
Insurance Fund also handles communication between health insurance organizations abroad in
co-operation with other piloting partners, especially Estonian Information System Authority.
Estonian Health Insurance fund is the Institution of the place of stay for Estonia, as defined in
Regulation 883/2004.
 Estonian Information System Authority (RIA) is coordinating the development and
administration of the national information system, to help the state to provide the best possible
services to citizens – project coordinator, technical advisor and possible candidate for the
location of the eConfirmation gateway.
 Health Care Providers are represented in pilot by East-Tallinn Central Hospital, West-Tallinn
Central Hospital and Medisoft Ltd.
o West-Tallinn Central Hospital is a modern health care institution with more than 500
hospital beds, almost 1,700 employees and high-level up to date medical services.
o East-Tallinn Central Hospital is a modern health care institution with more than 640
hospital beds and 2400 employees.
o Medisoft has been established in 1992 and is currently the biggest company in Estonia
producing social insurance and medical software. They also develop software for other
major information systems and registers. In pilot Medisoft represents Estonian family
doctors.
 The Estonian eHealth Foundation promotes and develops national e-solutions within the health
care system. They create solutions and offer services with the goal to assist in providing highquality and accessible health care services. Estonian eHealth Foundation is the Estonian liaison
body. eHealth Foundation is informed but not participating in the pilot.
9.1.4.
Pilot Timing
The eConfirmation pilot is part of wave 1 as decided by the e-SENS General Assembly.
Development of eConfirmation is planned in Q2 2015. During 2014, the design and planning has been
done. Estonian partners have committed themselves to the activities for design, planning and
implementation.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 143
9.2.
Pilot description
9.2.1.
Pilot scenario
Two scenarios can be derived from the eConfirmation business scenario. The first scenario is an
inbound scenario for an Estonian citizen who is in need for medical treatment in MS B, and needs a
document indicating his/her entitled to benefits in kind. The second is a scenario of a person on a
temporary stay in Estonia. This person needs a document indicating his/her entitlement in order to
present the document to an Estonian healthcare provider. The scenarios are performed under the
assumption that the healthcare provider is able to request a PRC with the consent of the person (if
possible).
al
Both scenarios, the inbound (MS-A scenario), and outbound (MS-B scenario) are included in the
Estonian pilot.
ov
9.2.1.1. Requests for an Estonian patient being abroad (being MS-A)
Pe
nd
in
g
EC
ap
pr
The figure below shows the architecture for the inbound scenario, when an Estonian person being
abroad needs a Provisional replacement certificate to indicate his/her entitlement to benefits in kind.
Figure 36: Inbound scenario – receiving a request document
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 144
The inbound scenario starts when the MS-B gateway sends a message to the Estonian gateway (RIAMSH). The MS-B gateway is authenticated and recognized as a trusted gateway. The RIA-MSH will
receive the message and will forward the payload to the Estonian Health Insurance Fund’s message
handler (Haigekassa-MSH). The interface between the RIA-MSH and the Haigekassa-MSH will be a
domestic interface (X-road asynchronous message queue).
The Haigekassa-MSH will receive and forward the message to the building block HIO-Connector,
which is responsible for processing the request. HIO-Connector will extract the document container,
check the entitlement of the person, and create a response. The response will be signed and sealed
in a document container, and sent back to the Haigekassa-MSH.
The Haigekassa-MSH forwards the payload to the RIA-MSH, which is responsible to deliver the
payload in a message to the MS-B gateway.
al
9.2.1.2. Request for a foreign patient in Estonia (being MS-B)
Pe
nd
in
g
EC
ap
pr
ov
The outbound scenario is a scenario of a person from a fellow MS who needs a Provisional
replacement certificate from the competent institution in MS-A. Estonian health care providers will
be enabled to request the Institution of the place of stay (IPS) to obtain a PRC using the Haigekassa’s
solution, as shown in the figure below. The RIA Gateway for cross-border message delivery is used to
send the request to MS-A and to receive the response.
Figure 37: Outbound scenario – sending a request document
The health care providers use national infrastructure (X-road) to send the request to the Estonian
Connector (corner 1), which is operated by Haigekassa. Haigekassa is also the Estonian Institution of
the place of stay. The connector produces a request document and sends it to the gateway for
transportation to MS-A. When the response is received and the seal has been verified, the result is
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 145
EC
ap
pr
ov
al
communicated to the health care provider. In case of a confirmation of entitlement, an electronic
Provisional replacement certificate is communicated.
Figure 38: Outbound scenario – receiving the response
Use of e-SENS and Domain-Specific Building Blocks
Pe
nd
9.2.2.
in
g
Communication of Haigekassa with the Health care provider is synchronous and uses existing
national network (X-road).
9.2.2.1. Register of Estonian health insurance policies (COV)
Haigekassa keeps record of the health insurance policies of all persons insured in Estonia. The
records are used for the electronic insurance confirmation service in Estonia. Health care providers
use the service to get all the data needed to claim the costs of treatment for a patient.
The records are used for the purpose of the electronic insurance entitlement confirmation service
(COV) in Estonia. Health care providers are using the service to get all the data needed to properly
claim the costs of medical treatment of a person. Estonian Health Insurance Fund will implement a
component to provide the service for eConfirmation.
9.2.2.2. eDelivery
RIA will implement the eDelivery BB based on selection made between two open source
implementations of the ebMS3/AS4 BB. These platforms are Jentrata and Domibus. The choice will
be made during the analysis phase of the project based on compatibility with existing infrastructure.
The secured Message service handler (RIA-MSH) will be able to act both as a sender and as a
receiver. Sending and receiving will be enabled by means of one or more processing modes.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 146
The addressing entity for receiving a document needs to be “EE” in the inbound scenario, as the
competent institution is determined by RIA. In the outbound scenario, the Estonian Institution Id
Number of the Institution of the place of stay needs to be used. Haigekassa uses EESSI number
“0001” due to historical reasons. During the analysis phase, feasibility of using of this number is being
analysed.
Since the Estonian gateway will act both as a sender and a receiver, both a trust store and a key store
are needed. The trust store will contain the server (receiver) certificate information (all the
certificates it will accept from clients (senders)). The key store will contain the client (sender)
certificate information (the certificates that will be provided to servers (receivers)). The trust store
and key store both hold SSL certificate information, and are password protected.
al
The certificates from the trust and key store will also be used to encrypt and sign the payload for
transportation. The transportation of payload between members of Estonian national network (XRoad) is encrypted by means of X-Road and there will be no additional encryption.
ov
A certificate issued by RIA will be used to authenticate the gateway for the pilot project.
pr
9.2.2.3. eDocuments
ap
The eDocuments BB will be implemented by Haigekassa. This BB will be based on existing national
BBs.
EC
9.2.2.4. eSignatures
Use of National infrastructure
in
9.2.3.
g
The eSignatures BB will be implemented by RIA and Heigekassa. This BB will be based on existing
national building blocks. Documents will be sealed by Haigekassa’s qualified certificate.
Pe
nd
Estonia applies a system of mandatory health insurance. The Estonian health insurance is executed
by a public institution called Estonian Health Insurance Fund (Haigekassa). All health care providers in
Estonia are connected to the information systems of the Estonian Health Insurance Fund. There are
two ways to connect to these systems – directly using national eInteraction network called X-road or
through the web portal created for family doctors by Medisoft. Both systems use X-road as their
authentication/encryption/trust establishing/communication channel. Therefore it is vital to provide
all services of the eDelivery gateway and eConfirmation service through the X-road infrastructure to
keep development and implementation costs down and to ensure long-term sustainability of the
solution being piloted. The scenario of a European health insurance confirmation will be integrated in
and will use this domestic infrastructure. The eConfirmation service will be provided within the
Haigekassa’s infrastructure.
Estonia has national infrastructure for digital signatures and handling digital documents, including
PKI. X-road infrastructure includes its own PKI managed by the Estonian Information System
Authority. Estonian Information System Authority will provide these services to pilot, including acting
as a certificate authority.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 147
9.3.
Pilot Implementation
9.3.1.
Implementation Planning
RIA will use a risk driven iterative approach to implement the eConfirmation solution. The solutions
of Haigekassa and RIA will be implemented in parallel and share the transport component and
signature validation component. Project start: Week 13-2015.
A project owner and project manager have been assigned for implementing the project.
Implementing development partner will be assigned after the public tender process is completed.
9.3.1.1. Detailed design of pilot
ov
9.3.1.2. Technical Implementation
al
The solution stories will be designed when a story of the solution is in a sprint.
pr
The technical implementation consists of the RIA implementation of the gateway and the
Haigekassa’s implementation of the connectors for the inbound and outbound scenarios.
EC
ap
Technical implementation will be based on existing components of the national infrastructure to be
modified to enable functionality required in pilot. This includes, but may not be limited to
components handling digital documents, digital signatures and eDelivery. To be compatible with
existing architecture and development framework, these components will be using Java and based
on open source projects or existing components of national infrastructure. Detailed overview of
these components is currently being done by the Estonian Information System Authority.
Pe
nd
in
g
The technical implementation will be performed iteratively in sprints. Every sprint, an increment of
the solution will be implemented and tested using mocks. The integration between the connectors
and the gateway will be tested as soon as possible.
The integration is realized using a national infrastructure (X-Road). To be compatible with e-SENS
architecture, X-road has to be modified to add an asynchronous file transfer component to the Xroads architecture. It is decided that this component will be based on ideology of Message Queues.
Details of the technical implementation will be identified by analysis.
9.3.1.3. Readiness Testing and Conformance
The readiness testing and conformance will be tested using scenarios. RIA and Haigekassa will assign
test coordinator(s) to support the readiness testing and conformance.
9.3.1.4. Launching and Running
The solution is planned to go live on Q3 2015.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 148
9.3.2.
Pilot resources
9.3.2.1. Estonian Information System Authority‘s team
During the pilot project, Estonian Information System Authority will have a project manager available
for implementing the eDelivery BB. Development of the solutions will be outsourced with estimated
total of 6 person-months.
RIA is also coordinating the Estonian pilot phase.
9.3.2.2. Haigekassa’s team
al
During the pilot project, Estonian Health Insurance Fund will have a project manager available for
implementing eDocument and eSignature BBs. Development of the solutions will be outsourced with
estimated total of 3 person-months.
ov
9.3.2.3. Medisoft’s team
ap
pr
During the pilot project, Medisoft will have a project team including 3 members. Medisoft’s project
team is responsible for organizing piloting by family doctors.
9.3.2.4. East Tallinn Central Hospital’s team
EC
During the pilot project, East Tallinn Central Hospital will have a project team of 2 members. East
Tallinn Central Hospital’s team is responsible for organizing piloting by East Tallinn Central Hospital.
g
9.3.2.5. West Tallinn Central Hospital’s team
Pe
nd
in
During the pilot project, West Tallinn Central Hospital will have a project team of 2 members. West
Tallinn Central Hospital’s team is responsible for organizing piloting by West Tallinn Central Hospital.
9.3.2.6. Funding
Apart from e-SENS funding, co-payment will take place by both RIA and Haigekassa. No other
national resources are available.
The Estonian coordinator applied for relocation of unused resources from partners not active in eSENS anymore due to restructuring of the project (Cybernetica, Sertifitseerimiskeskus) and using
some other e-SENS resources for creating eDelivery/eDocument/eSignature functionality required
for communication between MSs. This reallocation has been granted.
9.3.3.
Pilot risks and overall feasibility
9.3.3.1. Policy, organizational and business process factors
The Estonian business case can only be justified by providing the eConfirmation service to Estonian
citizens in/by other EEA MSs and providing sustainable and maintainable building blocks for
communication between ecosystems. So for Estonian partners there are two main goals to achieve in
piloting e-SENS building blocks:
 Partners should be able to demonstrate and use interoperability between different
ecosystems including countries in Estonia’s nearest neighbourhood. Therefore, we would
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 149

prefer to have maximum amount of piloting partners. Having maximum amount of piloting
partners would benefit the whole piloting process of the e-SENS project as well.
Building blocks to be developed and piloted should represent a sustainable platform for
usage outside of the domain they are being developed in.
The eConfirmation solution must be sustainable in the future, must be governed, and must keep
focus on connecting more Member states. This requires a formal governance structure with the
participating cCompetent institutions as members and contributors.
9.3.3.2.Legal factors
al
The participating competent institutions need to agree to conditions and policies of the General
Agreement, which describes the measures on security, privacy protection, performance, and
governance structure among others.
ov
9.3.3.3.Technical factors
ap
pr
The Estonian infrastructure is up and running. All health care providers and the Estonian Health
Insurance Fund are connected to this infrastructure. No technical obstacles are identified concerning
the implementation of the selected e-SENS Building Blocks so far. Asynchronous file transfer
component will be implemented as part of the eDelivery solution as additional component to X-road.
EC
9.3.3.4.Resourcing factors
in
9.3.3.5.Funding factors
g
The Estonian plan is part of project portfolio of 2015 for all participating partners and resources are
allocated.
Pe
nd
The budgets have been allocated to the project.
9.3.3.6.Feasibility in terms of timelines
The project is aiming at readiness for piloting beginning Q3 2015.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 150
10.National Pilot Plan of Netherlands for UC 5.2.2
10.1.
10.1.1.
Pilot Scope
Domain Use Case to be piloted
The Netherlands will pilot the eConfirmation domain use case (WP5.2.2) in the WP5.2 eHealth
domain.
10.1.2.
National Motivation and Goals
ov
al
Dutch citizens are entitled to benefits in kind in a fellow MS according to Regulation 883/2004, but
only if they are able to present a document indicating their entitlement. The competent institution
issues this document, the European health insurance card (EHIC).
EC
ap
pr
If the person does not have such a document, he/she can request the Institution of the place of stay
to contact the competent institution in order to obtain a Certificate provisionally replacing the
European health insurance card (PRC). The competent institution in MS A is most likely the institution
where the person is insured, but there are exceptions (e.g. border workers). The competent
institution is defined in article 1 of Regulation 883/2004.
g
All actors involved (insured persons, Institution of the place of stay, health care providers, and
competent institutions) in the current EHIC process face many disadvantages in terms of customer
friendliness, usability, efficiency, cost effectiveness, throughput times and quality of data.
Pe
nd
in
The eConfirmation service has the following advantages:
 A better experience for insured persons because they can use the documents they are used
to use in the Netherlands, such as passport or driver’s license.
 Insured persons will have no stress demonstrating their entitlement.
 Insured persons will not experience the risk of partially reimbursement (legal versus private
tariffs).
 Risk of fraud or misuse of cards is mitigated.
 Decrease of administrative handling costs and optimized processes for all actors involved in
the cross border health care provisioning.
 No costs for applying, processing, producing and issuing EHIC (recurring costs).
 Improving quality of administrative data.
Dutch partners are aiming to demonstrate that eConfirmation provides a state of the art, and cost
effective alternative for the current EHIC and PRC procedures.
10.1.3.
Business Process Overview
This use case describes how a health care provider (HCP) in a member state (MS-B) is able to obtain a
Provisional replacement certificate, being an electronic insurance confirmation and serving as a
payment guarantee for a person who is insured with a Competent institution in another member
state (MS-A). The use case takes place in the context of a person on a temporary stay who is in need
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 151
of medical treatment, and is not able to present a document indicating his entitlement to benefits in
kind (Regulation 987/2009 article 25).
The Institution of the place of stay contacts, upon request, the competent institution in MS-A. The
competent institution will issue the Provisional replacement certificate. The request received by the
Institution of the place of stay is submitted by the health care provider, and is sent with the
affirmative consent of the person.
The Provisional replacement certificate can be obtained using key attributes from documents such as
passports, driver’s license, or national or corporate insurance health cards. A person is familiar with
using these documents in his/her home country to obtain electronic evidence of entitlement. Some
insurance health cards are smart cards and might be read electronically.
Dutch pilot participants and stakeholders
al
10.1.4.
in
g
EC
ap
pr
ov
VECOZO is a joint venture of all health insurance companies in the Netherlands, which are private
companies. It develops and operates a communication infrastructure to communicate messages
between health care providers and health insurance companies in the Netherlands. But also
messages between health insurance companies and the Dutch Government are communicated
through VECOZO. Almost all Dutch health care providers and all health insurance organizations are
connected to VECOZO. VECOZO is aiming at providing cross-border services to their Dutch customers,
being health care providers and health insurance companies. VECOZO will be responsible for the
technical development of the eConfirmation pilot in the Netherlands. The health insurance
companies have been informed by the VECOZO Executives and they have agreed in the participation
of VECOZO in e-SENS, and in operating the eConfirmation service. VECOZO holds all Dutch health
insurance policies, which is continuously synchronised with the policy administration of the health
insurance companies.
Pe
nd
Zilveren Kruis Achmea (Groep Buitenlands Recht) is the Dutch Institution of the place of stay. Zilveren
Kruis Achmea is informed, but not participating in the pilot yet.
RINIS is a Dutch foundation to provide message delivery services to public organizations and will be
responsible for implementing the domain gateway.
CZ is a Dutch Health insurance organization with about 20% market share. CZ has a competitive edge
in providing a cross-border health insurance proposition both for the business and consumer market.
For that purpose, CZ cooperates with various international insurance partners. The eConfirmation
service contributes to CZ's strategic objectives. CZ is responsible for the coordination and business
acceptance of the e-Confirmation pilot in the Netherlands.
Zorginstituut Nederland (ZiNL) is the Dutch Liaison Body. ZiNL is informed, but not participating in the
pilot.
Ministery of Health (VWS) is informed, but not participating in the pilot.
Maybe all Dutch Health care providers will be recruited to participate in the pilot.
10.1.5.
Pilot Timing
The eConfirmation is part of wave 1 as decided by the e-SENS General Assembly.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 152
Development of eConfirmation is planned in Q1/Q2 2015. During 2014 the design and planning has
been done. VECOZO and CZ have committed themselves to the activities for design, planning and
implementation.
10.2.
Pilot Description
10.2.1.
Pilot scenario
ov
al
Two scenarios can be derived from the eConfirmation business scenario. The first scenario is an
inbound scenario for a Dutch citizen who is in need for medical treatment in MS B, and needs a
document indicating his/her entitled to benefits in kind. The second is a scenario of a person on a
temporary stay in the Netherlands. This person needs a document indicating his/her entitlement in
order to present the document to a Dutch Health care provider. The scenarios are performed under
the assumption that the health care provider is able to request a PRC with the consent of the person
(if possible).
pr
Both scenarios, the inbound (MS-A scenario), and outbound (MS-B scenario) are included in the
Dutch pilot.
ap
10.2.1.1.Requests for a Dutch patient being abroad (being MS-A)
Pe
nd
in
g
EC
The figure below shows the architecture for the inbound scenario, when a Dutch person being
abroad needs a Provisional replacement certificate to indicate his/her entitlement to benefits in kind.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 153
al
ov
pr
ap
EC
g
in
Figure 39: Inbound scenario – receiving a request document
Pe
nd
The inbound scenario starts when the MS-B gateway sends a message to the Dutch gateway. The MSB gateway is authenticated and recognized as a trusted gateway.
The RINIS-MSH will receive the message and will forward the payload to the VECOZO message
handler (VSP-MSH). The interface between the RINIS-MSH and the VSP-MSH will be a domestic
interface.
The VSP-MSH will receive and forward the message to the building block HIO-Connector, which is
responsible for processing the request. HIO-Connector will extract the document container, check
the entitlement of the person, and create a response. The response will be signed and sealed in a
document container, and sent back to the VSP-MSH.
The VSP-MSH forwards the payload to the RINIS-MSH, which is responsible to deliver the payload in a
message to the MS-B gateway.
10.2.1.2.Request for a foreign person in the Netherlands (being MS-B)
The outbound scenario is a scenario of a person from a fellow MS who needs a Provisional
replacement certificate from the competent institution in MS-A. Dutch Health care providers will be
enabled to request the Institution of the place of stay (IPS) to obtain a PRC using the VECOZO
solution, as shown in the figure below. The RINIS Gateway for cross-border message delivery is used
to send the request to MS-A and to receive the response.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 154
al
ov
pr
ap
Figure 40: Outbound scenario – sending a request document
Pe
nd
in
g
EC
The health care provider uses the VECOZO interfaces (web service and website) to send the request
to the Dutch Connector (corner 1), which is operated by VECOZO under the responsibility of the
Dutch Institution of the place of stay. The connector produces a request document and sends it to
the gateway for transportation to MS-A. When the response is received and the seal has been
verified by or on behalf of the IPS, the result is communicated to the Health care provider. In case of
a confirmation of entitlement, an electronic Provisional replacement certificate is communicated.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 155
al
ov
pr
ap
Figure 41: Outbound scenario – receiving the response
EC
Communication with the Health care provider is asynchronous.
Use of e-SENS and Domain-Specific Building Blocks
Pe
nd
10.2.2.
in
g
The electronic Provisional replacement certificate also needs to be integrated with the back office of
the Dutch Institution of the place of stay. Although VECOZO has done already a pilot together with
the Institution of the place of stay, it is not yet sure whether this will be done during the e-SENS pilot.
10.2.2.1.Register of Dutch health insurance policies (COV)
VECOZO keeps record of the health insurance policies of all the people insured by the Dutch health
insurance companies. These records do not contain all the information, but are just aiming at
enabling Health care providers to verify whether, and if yes with which Health insurance Company a
person is insured.
VECOZO continuously updates the records from the source, the policy administration of the Dutch
Health insurance companies.
The records are used for the purpose of the electronic insurance entitlement confirmation service
(COV) in the Netherlands. Health care providers are using the service to get all the data needed to
properly claim the costs of medical treatment of a person.
10.2.2.2.eDelivery
RINIS will implement the eDelivery building BB using the open source of Jentrata, and will act as the
gateway to the Netherlands. The choice for RINIS is based on their experience with ebMS2, and their
role of Access Point in EESSI.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 156
The secured Message service handler (RINIS-MSH) will be able to act both as a sender and as a
receiver. Sending and receiving will be enabled by means of one or more processing modes.
The addressing entity for receiving a document needs to be “NL” in the inbound scenario, as the
competent institution is determined by VECOZO. In the outbound scenario, the Dutch Institution Id
Number “7125” of the Institution of the place of stay needs to be used.
Since the Dutch gateway will act both as a sender and a receiver, both a trust store and a key store
are needed. The trust store will contain the server (receiver) certificate information (all the
certificates it will accept from clients (senders)). The key store will contain the client (sender)
certificate information (the certificates that will be provided to servers (receivers)). The trust store
and key store both hold SSL certificate information, and are password protected.
ov
al
The certificates from the trust and key store will also be used to encrypt and sign the payload for
transportation. The payload is received from VECOZO unencrypted and is forwarded to VECOZO
unencrypted by RINIS.
pr
A certificate issued by VECOZO will be used to authenticate the gateway.
Alternatives to RINIS as gateway
ap
VECOZO researched also some alternatives to the RINIS implementation of the gateway.
EC
One of the alternatives was an in-house development of an ebMS3/AS4 solution using WCF.
Suppliers offer adapters for Microsoft BizTalk, but VECOZO does not want BizTalk for integration.
Other open source or commercial solutions in the Microsoft stack are not available, or not very
mature.
in
g
Development by VECOZO would have had a high learning curve because it would require a deep
understanding of ebMS3 and the AS4 profile, and very low-level programming in WCF.
Pe
nd
Another alternative was using an open source or commercial implementation from another stack.
DOMIBUS for example has been developed by a large-scale project connected to the European
Union. The implementation will support the ebMS3/AS4 profile. A java implementation would not fit
in the Microsoft oriented environment of VECOZO. It would require knowledge and support for java
as well.
10.2.2.3.eDocuments
The eDocuments building block will be implemented by VECOZO using commercial software,
probably SecureBlackbox (https://www.eldos.com/sbb/desc-asic.php).
10.2.2.4.eSignatures
The eSignatures building block will be implemented by VECOZO using commercial software, probably
SecureBlackbox (https://www.eldos.com/sbb/desc-asic.php).
A certificate, not a qualified certificate, issued by VECOZO will be used to seal the documents.
10.2.3.
Use of National infrastructure
For all regular (short-term) medical treatment, there is a system of mandatory health insurance.
Private health insurance companies execute the Dutch health insurance system. In the last decade,
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 157
the health insurance companies have invested in a Dutch infrastructure, to exchange information to
contract health care providers, electronic insurance confirmation, claiming, etc. In this respect,
VECOZO acts as a facility centre of all Dutch health insurance organizations. VECOZO has
implemented this infrastructure and provides these services. VECOZO connects more than 97% of all
health care providers in the Netherlands to the health insurance organizations, both cure and care.
Dutch health care providers are used to apply the VECOZO infrastructure. The scenario of a European
health insurance confirmation will be integrated in and will use the domestic infrastructure. The
infrastructure consists of secure web services to enable Health care providers to integrate their
information systems with VECOZO's services. Most Health care providers are connected this way.
Alternatively a VECOZO web portal is provided. The eConfirmation service will be provided within
the VECOZO infrastructure.
Pilot Implementation
Implementation Planning
ap
10.3.1.
pr
10.3.
ov
al
VECOZO acts as a certificate authority to provide certificates to Health care providers enabling them
to connect to the VECOZO services.
VECOZO will use a risk driven iterative approach (SCRUM) to implement the eConfirmation solution.
EC
The solutions of VECOZO and RINIS are being implemented in parallel. Project start: week 9-2015.
Pe
nd
in
g
A project owner and a development team have been assigned for implementing the project.
10.3.1.1.Detailed design of pilot
The solution stories will be designed when a story of the solution is in a sprint.
10.3.1.2.Technical Implementation
The technical implementation consists of the RINIS implementation of the gateway and the VECOZO
implementation of the inbound and outbound scenarios.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 158
The technical implementation will be performed iteratively in sprints. Every sprint, an increment of
the solution will be implemented and tested using mocks. The integration between the connectors
and the gateway will be tested as soon as possible.
The integration is realized using a web service interface between VECOZO and RINIS (VSP-Koppeling).
The implementation of this interface is a dependency with another project.
10.3.1.3.Readiness Testing and Conformance
The readiness testing and conformance will be tested using scenarios. VECOZO has assigned a test
coordinator to support the readiness testing and conformance.
10.3.1.4.Launching and Running
Pilot resources
ov
10.3.2.
al
The solution is planned to go live on Q3 2015.
ap
pr
During the pilot project, VECOZO and RINIS will have a development team available for implementing
the eConfirmation solution. CZ is coordinating both the Dutch pilot phase and the eConfirmation
pilot on workgroup WP5.2.2 level. The resource demand for CZ during the pilot phase will be in line
with the average resource consumption during the previous project phase.
EC
10.3.2.1.Funding
Pilot risks and overall feasibility
Pe
nd
10.3.3.
in
g
Apart from e-SENS funding, co-payment will take place by both VECOZO and CZ. No other national
resources are available. Because of their private organizational status, VECOZO and CZ have joined eSENS.com to safeguard their e-SENS funding.
10.3.3.1. Policy, organizational and business process factors
The VECOZO's Board of Directors has approved the investments needed for the pilot with the
constraint that more MSs will participate, in order to justify the business case. The Dutch business
case can only be justified by providing the eConfirmation service to Dutch citizens in/by other MS.
This means that a proper number of MSs should demonstrate their willingness to implement the
service after the pilot phase.
Since the number of piloting MS is poor (so far only Estonia, the Netherlands and Poland intend to
pilot, the other MSs are uncertain), the potency of a widely spread roll out of the service is not
convincing. There is a strong need that Austria, Slovakia, and Greece will join the eConfirmation pilot
as well.
The eConfirmation solution must be sustainable in the future, must be governed, and must keep
focus on connecting more Member states. This requires a formal governance structure with the
participating competent institutions as members and contributors.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 159
10.3.3.2. Legal factors
The participating competent institutions need to agree to conditions and policies of the General
Agreement, which describes the measures on security, privacy protection, performance, and
governance structure among others.
10.3.3.3. Technical factors
ov
al
The Dutch infrastructure is up and running and almost all health care providers and all health
insurance organizations are connected to VECOZO. No technical obstacles are identified concerning
the implementation of the selected e-SENS Building Blocks. Moreover the research done by RINIS, to
act as the Dutch eConfirmation gateway did not result in additional obstacles. A decision is needed
soon whether eDelivery will be implemented in the Netherlands under responsibility of RINIS or
VECOZO.
10.3.3.4. Resourcing factors
ap
pr
The Dutch pilot plan is part of VECOZO's and RINIS project portfolio of 2015 and resources are
allocated.
10.3.3.5. Funding factors
EC
The budgets have been allocated to the project. Since both VECOZO and CZ are private organizations,
they are part of e-SENS.com.
g
10.3.3.6.Feasibility in terms of timelines
Pe
nd
in
The project is aiming at readiness for piloting end of Q2/2015.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 160
11.National Pilot Plan of Poland for UC 5.2.2
11.1.
Pilot Scope
11.1.1.
Domain Use Case to be piloted
Poland will pilot the eConfirmation domain use case (WP5.2.2) in the WP5.2 e-Health domain.
11.1.2.
National Motivation and Goals
pr
ov
al
According to the EU Regulation Polish citizens are entitled for health care in a fellow EU/EES MS only,
by showing a valid EHIC. In case the citizen has no EHIC with him, he can ask his HIO to issue a
provisional replacement document (PRC). All actors involved (Citizens, HCPs, CIs, Liaison Bodies) in
the current EHIC/PRC process face many disadvantages in terms of customer (citizen) friendliness
and usability, efficiency, cost effectiveness, throughput times and quality of data.
eConfirmation aims at taking away all these disadvantages by:
Facilitating patient's access to health care during a temporary stay in a fellow MS in case of
not possession of EHIC

Decreasing administrative handling costs for all actors involved in the cross border health
care provision

Optimizing administrative processes referring to cross border health care for all actors
involved

Improving quality of administrative data.
Pe
nd
in
g
EC
ap

Pilot value from Polish perspective
Polish partners are aiming to demonstrate that eConfirmation provides modern solution of effective
achieving indispensable data from a database maintained in MS-A, which are necessary to confirm
patient’s rights to health care services under Social Security regulations in MS-B in case of not
possessing the EHIC.
Piloting of eConfirmation also shows the need, advantage and technical ability of connecting HCP to
a network of actors in an electronic process of data exchange corresponding to the currently running
standard process of receiving the PRC.
Goals of NFZ
In WP5.2.2 the NFZ will be the active Polish partner. The main goal of NFZ is to implement a solution
that will embrace selected Building Blocks developed by WP6 in order to build pan-European channel
of data exchange in eConfirmation process as MS-A and MS-B.
It is also important to show domestically that the same process of electronic verification of national
healthcare insurance, which is currently successfully exploited in Poland, can be used in panEuropean scope as modern alternative for the PRC issuance procedure.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 161
When the pilot will be successfully carried out, it can show the future direction of evolution of panEuropean process of verification of entitlement in the healthcare services provision under Social
Security regulations. In the future, eConfirmation implemented on a large scale could replace the
need of issuing EHIC in such a huge numbers. In case of Poland, where EHIC is issued on demand and
only for limited period, it would be business-critical saving cost decision to decrease the number of
EHICs in use.
11.1.3.
Business Process Overview
Pilot participants and Stakeholders
ov
11.1.4.
al
The business scenario consists of a patient being abroad on a temporary stay in a MS-B of the
EU/EES. The patient in need for health care is consulting a health care provider in a fellow MS for
medical treatment. The health care provider must be able to request and receive an electronic
insurance confirmation from the health insurance organization in the MS-A.
pr
NFZ
ap
The NFZ will be responsible for the technical development, implementation, and testing of the
eConfirmation UC both as MS-A and as MS-B.
EC
In Poland, NFZ plays a role of Health Insurance Organization and Liaison Body as well. This is a crucial
factor of a decision to run the Pilot as the MS-A and MS-B.
Pe
nd
in
g
In the role of MS-A the NFZ will deliver an eConfirmation response with the information about
entitlement to healthcare services. NFZ currently maintains the national database containing
information about entitlement of Polish citizens. There is an IT system that processes HCP’s
questions and NFZ’s responses about patient’s entitlement. As the Liaison Body, NFZ will be
responsible for receiving of the request from MS-B and sending back the eConfirmation response.
In the MS-B role the NFZ will be responsible for organisation of a secure access of the authorized
HCPs to the services enabling sending the request for eConfirmation. As the Liaison Body in this case
the NFZ will send this request to MS-A and receive eConfirmation response from MS-A. This response
will be conveyed to HCP.
Health Care Providers
At the beginning of a pilot NFZ will cooperate with few chosen HCPs which are the leaders in
integration of IT solutions. After positive tests on data exchange, documentation with specification
and instructions will be published and other HCPs who have contracts with NFZ and want to integrate
their IT systems with eConfirmation services can join the project. For HCPs who don’t use webservice solutions, a web portal will be prepared.
As Health Insurance Organisation NFZ has already a running solution for authentication and
authorization of HCPs in the field of entitlement verification of Polish patients.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 162
11.1.5.
Pilot Timing
Pilot as MS-A
Development phase can start after final agreement on XML structure among eConfirmation partners.
Developer needs ca 3-4 months from the day of agreed specification to adjust already existed IT
system to interface with eConfirmation process (receiving the request from Gateway and providing
the eConfirmation response including eSignature BB to Gateway).
al
Implementation of the Gateway packages can start after receiving information that eDelivery BB,
eSignature BB and eDocuments BB are ready for installation. Depending on the quality of the
delivered software and documentation it may take one to few weeks to install, integrate and test the
Gateway.
ov
Pilot as MS-B
ap
pr
IT system which is responsible for authentication and authorization of HCPs who are allowed to use
the service of entitlement verification of Polish patients already exists. Developer needs 3-4 months
to develop a web portal dedicated to eConfirmation and to integrate it with the Gateway.
Development phase can start after ultimate agreement on XML structure.
EC
An installation of the Gateway can start after receiving information that eDelivery BB and
eDocuments BB are ready for use. It will take few weeks to install, integrate and test the Gateway.
11.2.1.
g
Pilot description
Pilot scenario
in
11.2.
Pe
nd
The NFZ will perform the technical development, implementation, and testing of the eConfirmation
UC both as MS-A and as MS-B.
11.2.1.1.Request for a Polish patient being abroad (being MS-A)
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 163
al
ov
pr
ap
EC
g
Pe
nd
in
11.2.1.2.Request for a foreign patient treated in Poland (being MS-B)
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 164
al
ov
pr
ap
EC
g
Use of e-SENS and Domain-Specific Building Block
in
11.2.2.
Pe
nd
NFZ will adjust to eConfirmation standards actually running IT system that processes HCP’s questions
and NFZ’s responses about patient’s entitlement. Connection with access points in other partner
countries will be accomplished by installing selected BBs.
NFZ currently maintains the national database containing information about entitlement of Polish
citizens. There is an IT system that processes HCP’s questions and NFZ’s responses about patient’s
entitlement. As the Liaison Body, NFZ will be responsible for receiving of the request from MS-B and
sending back the eConfirmation response including information from national database.
11.2.2.1.eDelivery
NFZ will implement the eDelivery BB delivered by the e-SENS project.
11.2.2.2.eDocuments
NFZ will implement the eDocuments BB delivered by the e-SENS project.
11.2.2.3.eSignatures
NFZ will implement the eSignatures BB delivered by the e-SENS project.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 165
11.2.3.
Use of National infrastructure
Gateway MS-A and MS-B will be installed within infrastructure which is operated in NFZ.
Functionalities which give HCPs opportunity to make the request for eConfirmation in pilot as MS-B
will be treated as extension of NFZ IT system. NFZ will provide web portal to HCPs who will join the
project. This portal will allow them to make an eConfirmation request and get eConfirmation
response. Other HCPs who want to use web-service offered by the NFZ will adjust their IT solution to
domestically defined specifications.
Functionalities providing eConfirmation in pilot as MS-A will be treated as extension of NFZ IT
system.
11.3.1.
Implementation Planning
al
Pilot Implementation
ov
11.3.
ap
pr
NFZ does not have sufficient human resources competent to conduct the implementation in analytic
and developing scope without support of external technical experts. eConfirmation functionalities
will be an extension of NFZ IT system which is serviced and developed by IT consortium within the
contract with NFZ. As a scope of this contract does not contain services needed to implement
eConfirmation, NFZ should buy additional consulting services.
EC
11.3.1.1.Detailed design of pilot
Detailed design of pilot is part contract for consulting services which was finally signed.
in
g
11.3.1.2.Technical Implementation
Pe
nd
Technical implementation of functionalities depicted on the charts above will be conducted by IT
consortium which cooperates with NFZ within the contract. It can start after ultimate agreement of
XML structure and receiving Building Blocks with proper documentation.
11.3.1.3.Readiness Testing and Conformance
Readiness for testing and conformance should be achieved after about 3 months from starting
technical implementation.
11.3.1.4.Launching and Running
NFZ plans launching and running of pilot after positive test phase.
11.3.2.
Pilot resources
NFZ resources are being supported by technical experts under consulting agreement.
NFZ has planned sufficient internal resources and subcontracting expenses. Most of recourse
consumption and subcontracting will be carried out during pilot phase.
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 166
1.2.1
Pilot risks and overall feasibility
The pilot risks include the following:
Time consuming tender procedures on the national level required to get technical support
for the project;

The quality of the solutions (BBs) and documentation delivered by WP6;

A political decision on priorities of the NFZ that may lead to an abandonment of the project.
Pe
nd
in
g
EC
ap
pr
ov
al

D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 167
I. References
[AS4]
AS4 Profile of ebMS 3.0 Version 1.0. OASIS Standard, 23 January 2013.
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/
[ETSIASIC]
ETSI TS 102 918 V1.1.1 (2011-04)
Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC)
http://www.etsi.org/deliver/etsi_ts/102900_102999/102918/01.01.01_60/ts_102918
v010101p.pdf
OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features. OASIS Standard. 1
October 2007.
al
[EBMS3]
ov
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/os/
Electronic Signatures and Infrastructures (ESI); XAdES Baseline Profile,
http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171
v020101p.pdf
[WIKI]
e-SENS Wikis – e-SENS Building Blocks
ap
pr
[XADES]
Pe
nd
in
g
EC
http://wiki.ds.unipi.gr/display/20141201ESENS/WP6+-+Building+Blocks
D5.4-2 Second-wave Update of Plans and Status of Domain and National Pilots in eHealth
Page 168