Agreement between National Authorities or National Organisations responsible for
National Contact Points for eHealth on the Criteria required for the participation in
Cross-Border eHealth Information Services
Table of contents
Glossary of abbreviations and definitions 2
Chapter I General objective and scope 3
Chapter II Criteria required for the participation in CBeHIS 5
Chapter III Governance 10
Annex 14
1
Glossary of abbreviations and definitions
CBeHIS Cross-Border eHealth Information
Services that are processed via NCPeH for
the purpose of cross-border healthcare, as
they were agreed by the eHN (Patient
Summary for unscheduled care;
ePrescriptions and eDispensations) and as
they will be agreed by the eHN in the
future
Contracting Party National Authority or National
Organisation responsible for NCPeH in a
Member State of the EU or EFTA that has
signed this Agreement
Country A Member State of affiliation according to
Art. 3 (c) of Directive 2011/24/EU
Country B Member State of treatment according to
Art. 3 (d) of Directive 2011/24/EU
Cross-border healthcare Term as defined in Art. 3 (a) and (e) of
Directive 2011/24/EU
EFTA European Free Trade Association
eHDSI eHealth Digital Service Infrastructure
enabling the provision of CBeHIS via
NCPeH as Generic Services under the
responsibility of the Contracting Parties
and Core Services as described in the
documents that are referred to in the
Annex
eHN eHealth Network according to Article 14
of Directive 2011/24/EU
EU European Union
Governing Body eHN or another body agreed by the eHN
Healthcare provider Term as defined in Art. 3 (g) of Directive
2011/24/EU
Health professional Term as defined in Art. 3 (f) of Directive
2011/24/EU
National Authority or National Ministry responsible for eHealth, or an
Organisation responsible for NCPeH organisation at a lower level that has the
original or delegated competence of either
operating the NCPeH and/or signing this
Agreement, or an Authority at an even
higher level than the Ministry responsible
for eHealth (e.g. Government as collegial
organ) as required by the national laws and
procedures of a Contracting Party. In any
case, the link between the respective
Contracting Party and its National
Authority as Member of the eHN must
always remain established
NCPeH National Contact Point for eHealth, acting
as organisational and technical gateway for
the provision of CBeHIS
2
Chapter I
General objective and scope
Clause I.1
(1) The eHealth Network (eHN) set up under Article 14 of Directive 2011/24/EU is the
main political and strategic Governance Body for eHealth in Europe, connecting the
National Authorities responsible for National Contact Points for eHealth (NCPeH). The
eHN has the mandate to establish an European Interoperability Framework for Cross-
Border eHealth Information Services (CBeHIS) with a view to achieving a high level of
trust and security, enhancing continuity of care and ensuring access to safe and high-
quality healthcare.
(2) Whereas organisational, semantic and technical interoperability have been worked
upon by the eHN, the establishment of an overall interoperability framework remains
needed for the achievement of the objectives under Directive 2011/24/EU, notably
Articles 11 and 14 thereof. This requires an even closer cooperation among the
Contracting Parties by way of displaying the legal criteria laid down in EU law and the
Contracting Parties' national laws to be adhered to for the purpose of providing CBeHIS.
(3) This Agreement materializes the commitment of the Contracting Parties to fulfil all
the criteria required for the participation in CBeHIS. The details of specifications for the
implementation and organisation of these requirements are described in the binding
documents that are referred to in the Annex. The elaboration of these documents follows
a progressive approach through different stages, as described in the documents that are
referred to in the Annex, in order to achieve a sustainable framework.
(4) This Agreement thus describes the criteria for the processing of personal data
concerning health for the purpose of cross-border healthcare according to Directive
2011/24/EU by means of the CBeHIS.
Clause I.2
(1) Ensuring continuity of cross-border healthcare depends on transmission of personal
data concerning patients’ health. These personal data should flow from one Contracting
Party to another, while at the same time the fundamental rights of the patients shall be
safeguarded.
(2) This requires that each Contracting Party of a Country A provides the patient with
adequate, correct and up to date information about the transmission of his or her personal
data to a Contracting Party of a Country B, together with ensuring the secure transmission
of the data to this Contracting Party of a Country B.
(3) Each Contracting Party of a Country B shall ensure secure receipt of this data and
provide the appropriate level of protection when data is processed, in conformity with
national law and Union provisions on the protection of personal data, in particular
Regulation 2016/679/EU and also ensure the secure transmission of data to the
Contracting Party of a Country A.
Clause I.3
(1) Contracting Parties to this Agreement may be the National Authorities or National
Organisations responsible for NCPeH in Member States of the EU and EFTA.
(2) All National Authorities or National Organisations are free to choose whether to
participate in the signature of this voluntary Agreement, depending on which CBeHIS
they wish to offer as a Contracting Party of a Country A and/or Country B.
3
(3) Once a National Authority or National Organisation has chosen to become a
Contracting Party to this Agreement, it is obliged to fulfil the criteria required herein in
order to be admitted to participate in the CBeHIS according to paragraph (2).
(4) All Contracting Parties have the right to choose, in accordance with EU law and their
respective national law, the method for the fulfilment of the required criteria.
Clause I.4
The eHN shall amend the Agreement according to Clause III.1.1.3 within 12 months from
the adoption of the Agreement on 9 May 2017, depending on the need for such an
amendment based on the evaluations and conclusions reached until then.
4
Chapter II
Criteria required for the participation in CBeHIS
Section 1: Legal criteria
Clause II.1.1
Data protection and security
Clause II.1.1.1
Legal basis for the cross-border processing and patient information
(1) The processing of personal data concerning health for the purpose of cross border
healthcare pursuant to Directive 2011/24/EU via CBeHIS is lawful in compliance with
the conditions stated in Regulation 2016/679/EU, in particular Articles 6 and 9 thereof,
and national law compliant with the stated Regulation.
(2) Each Contracting Party shall ensure that further processing of personal data
concerning health by the same controller complies with the principles and conditions
stated in Regulation 2016/679/EU, in particular Article 5 paragraph (1) lit. (b), in
conjunction with Article 89, or Article 6 paragraph (4) thereof, and national law
compliant with the stated Regulation.
(3) With regard to secondary use of personal data concerning health for archiving
purposes in the public interest, scientific or historical research purposes or statistical
purposes, each Contracting Party shall ensure that the secondary use is in compliance
with the conditions stated in Regulation 2016/679 EU, in particular Articles 6, 9 and 89
thereof, and national law compliant with the stated Regulation.
(4) Each Contracting Party shall ensure that patients are provided with the information
pursuant to Articles 13 and 14 of Regulation 2016/679/EU. With regard to further
processing according to paragraphs (2) and (3) of this Clause in a Country B, each
Contracting Party of a Country B shall ensure that patients are informed that their
personal data will be processed in conformity with the national law of Country B,
including information about the extent of the rights of the data subjects granted therein.
Clause II.1.1.2
Identification and authentication of patients, health professionals and healthcare providers
(1) In order to enhance patient safety and privacy in cross-border healthcare, Contracting
Parties shall ensure the unambiguous identification of patients, health professionals and
healthcare providers, without prejudice to Regulation 2014/910/EU:
a.) Contracting Parties using electronic means of identification that are notified under
Regulation 2014/910/EU and applicable to the health domain, shall adhere to this
Regulation, its Implementing Acts and the documents that are referred to in the Annex.
b.) Contracting Parties using non-electronic means of identification, or using electronic
means of identification not notified under Regulation 2014/910/EU, or using electronic
means of identification that are notified under Regulation 2014/910/EU but not applicable
to the health domain, shall adhere to the relevant documents listed in the Annex.
(2) Each Contracting Party shall ensure that it uses means of authentication that are
adequate to the sensitivity of personal data concerning health according to Regulation
2014/910/EU and Regulation 2016/679/EU.
5
Clause II.1.1.3
Authorization of health professionals
Each Contracting Party of a Country B shall ensure that for the purpose of cross-border
healthcare only health professionals authorized according to its national law may have
access to patients’ data concerning health, without prejudice to other lawful grounds for
processing under Regulation 2016/679/EU.
6
Clause II.1.2
Liability, applicable law and jurisdiction
(1) The civil liability of each designated NCPeH as Generic Services under the
responsibility of the Contracting Parties is determined by the liability regime in
accordance with the applicable law and competent jurisdiction.
(2) The Contracting Parties do not assume any liability for Core Services as described in
the documents that are referred to in the Annex.
7
Section 2: Organisational criteria
Clause II.2
Processing of personal data concerning health via NCPeH
Each Contracting Party shall designate one NCPeH to act as a single communication
gateway with the NCPeH designated by other Contracting Parties. In order to be admitted
to participate in the CBeHIS according to the process defined under Clause III.1.2.1 of
this Agreement, each Contracting Party shall ensure the compliance of its NCPeH with
the criteria set forth in this Agreement, taking into account the relevant processes and
criteria defined in the documents that are referred to in the Annex.
8
Section 3: Semantic criteria
Clause II.3
Semantic processing
(1) Each Contracting Party shall ensure semantic processing as needed for the provision
of cross-border healthcare via CBeHIS.
(2) Each Contracting Party is responsible for the accuracy and integrity of semantic
processing and must therefore use the most recently adopted version of the Master Value
Set Catalogue and maintained national versions of these controlled vocabularies used in
semantic processing.
(3) In order to be admitted to participate in the CBeHIS according to the process defined
under Clause III.1.2.1 of this Agreement, each Contracting Party shall ensure the
compliance of its NCPeH with the criteria set forth in this Agreement, taking into account
the relevant processes and criteria defined in the documents that are referred to in the
Annex.
9
Section 4: Technical criteria
Clause II.4.1
Security Principles
In order to be admitted to participate in the CBeHIS according to the process defined
under Clause III.1.2.1 of this Agreement, each Contracting Party shall ensure the
compliance of its NCPeH with the principles of data protection by design and by default,
the requirements for confidentiality, integrity, authenticity, availability, non-repudiation,
encryption and other means of data security and control measures in compliance with
Regulation 2014/910/EU and Regulation 2016/679/EU, taking into account the relevant
processes and criteria defined in the documents that are referred to in the Annex.
Clause II.4.2
Traceability, audit and non-repudiation
In order to be admitted to participate in the CBeHIS according to the process defined
under Clause III.1.2.1 of this Agreement, each Contracting Party shall ensure the
compliance of its NCPeH with the requirements for logs, audit trails, non-repudiation and
other means of data security and control measures in compliance with Regulation
2014/910/EU and Regulation 2016/679/EU, taking into account the relevant processes
and criteria defined in the documents that are referred to in the Annex.
10
Chapter III
Governance
Section 1: Governance for this Agreement
Clause III.1.1
Signature, entry into force, term and termination
Clause III.1.1.1
Signature
(1) In accordance with Clause I.3, this Agreement shall be open to the participation of
National Authorities or National Organisations responsible for NCPeH in Member States
of the EU and EFTA that meet the criteria required for the participation in CBeHIS as set
out by this Agreement and taking into account the documents that are referred to in the
Annex.
(2) The duplicate of the Agreement that is singed by the representative of the Contracting
Party duly authorized according to national laws and procedures shall be provided to the
Governing Body. In case the signatory is not the respective Member of the eHN, a written
approval from the Ministry responsible for eHealth shall be provided. The Agreement
will remain open for signature for an indefinite time. The Governing Body shall keep one
signed version of the Agreement of all the Contracting Parties.
(3) The signing of this Agreement is one criterion for the admission in accordance with
Clause III.1.2.1, as described in the documents that are referred to in the Annex. The
signature of the Agreement by a Contracting Party means that it accepts, subject to
paragraph (4), to adhere unconditionally to all legal criteria set out in this Agreement.
(4) Contracting Parties may express their consent to be bound by this Agreement subject
to approval according to their national laws and procedures. This approval must be
granted in order to complete the signing of this Agreement as one criterion for the
admission in accordance with Clause III.1.2.1.
Clause III.1.1.2
Term and termination
(1) This Agreement shall subsist until it is either replaced by another Agreement or
legislative act, or is terminated in accordance with paragraph (2).
(2) This Agreement shall be terminated if agreed in writing unanimously by the
Contracting Parties.
Clause III.1.1.3
Amendment of the Agreement
(1) This Agreement may be amended only in writing. Any Contacting Party or Member
of the eHN may propose amendments to this Agreement by forwarding a proposal for
11
amendment to the Governing Body. Upon receiving such a proposal, the Governing Body
shall forward the proposal to the other Contracting Parties and Members of the eHN.
(2) The Agreement may be amended by the eHN in accordance with the procedure
defined in Article 7 of the Rules of Procedures of the eHN.
Clause III.1.2
Admission, withdrawal and exclusion, dispute resolution
Clause III.1.2.1
Admission:
Each Contracting Party that has signed this Agreement shall be admitted by the eHN to
participate in the CBeHIS if the compliance of its NCPeH with the criteria set forth in this
Agreement is established, taking into account the relevant processes and criteria defined
in the documents that are referred to in the Annex.
Clause III.1.2.2
Withdrawal, exclusion and technical suspension
(1) Contracting Parties are entitled to terminate their participation in the Agreement.
Withdrawal of a Contracting Party requires a written declaration of the Contracting Party
to the Governing Body with a notice period of 4 (four) months. The right to withdraw
without notice period for good cause in written form shall remain unaffected. It shall
constitute good cause, in particular and without limitation, if
a) the Agreement contradicts national legislation;
b) the continued operation would severely harm the interests of the Contracting
Party.
(2) A Contracting Party may accede to the Agreement again at any time without a
readmission ban after the withdrawal of that Contracting Party has become effective,
according to the process defined under Clause III.1.2.1.
(3) The eHN shall exclude a Contracting Party if the Contracting Party ceases to have
legal capacity or ceases to exist. The eHN may exclude a Contracting Party for good
cause according to paragraph (4).
(4) The exclusion of the Contracting Party shall take immediate effect as of the date of
the decision of the eHN. The Contracting Party must be notified by the eHN of the
decision in writing. It shall constitute good cause, in particular and without limitation, if
a. the continued operation of the relevant Contracting Party would harm the aim and
main interests of this Agreement;
b. a Contracting Party repeatedly infringes the provisions of this Agreement despite
a written reminder by the Governing Body.
(5) Immediate interim technical suspension from the CBeHIS of a Contracting Party at its
own discretion or by the Governing body may be executed in case the Contracting Party
or the Governing Body identifies a risk or an incident as defined under Directive
2016/1148/EU. All other Contracting Parties shall be immediately informed thereof by
the respective Contracting Party suspending at its own discretion or by the Governing
Body, without prejudice to any obligations under the mentioned Directive. The duration
of the immediate interim technical suspension of a Contracting Party from the CBeHIS is
indefinite. Technical suspension from the CBeHIS of a Contracting Party ends either
12
when the Governing Body decides that the Contracting Party again meets all the set
criteria or the eHN decides upon the exclusion of the Contracting Party from the
Agreement according to paragraph (4).
(6) As of the effective termination of participation in the Agreement, the respective
Contracting Party shall no longer be entitled to any rights. Such termination shall not
affect commitments entered into or liabilities incurred by the respective Contracting Party
prior to such termination.
Clause III.1.2.3
Dispute Resolution
(1) Any dispute between the Contracting Parties about the interpretation of any provision
of this Agreement or the documents that are referred to in the Annex shall be resolved
amicably and informally, as far as possible, pursuant to this Clause.
(2) Prior to the initiation of any formal dispute resolution proceedings including litigation,
the Contracting Parties shall first attempt to resolve their dispute informally, as follows:
a. upon the written request of either Contracting Party to the other, each Contracting
Party shall appoint a designated representative for the purpose of endeavouring to
resolve such dispute;
b. the designated representatives shall meet as often as either Contracting Party
reasonably deems necessary in order to gather and furnish to the other all
information with respect to the matter in issue which the Contracting Party
believes to be appropriate in connection with its resolution. The designated
representatives shall discuss the problem and negotiate with each other in good
faith in an effort to resolve the dispute informally;
c. during the course of negotiations, all reasonable requests made by either
Contracting Party to the other for non-privileged information, reasonably related
to the Agreement, shall be honoured in order that each of the Contracting Parties
may be fully advised of the other's position; and
d. the method of endeavouring to resolve the dispute shall be left to the discretion of
the designated representatives.
(3) Neither Contracting Party shall commence formal dispute resolution proceedings
including litigation, until the earlier of:
a. at least one of the Contracting Parties' designated representatives as referred to in
paragraph (2) concluding that resolution of the dispute through continued
negotiation of the matter does not appear likely; or
b. 30 (thirty) Working Days after either Contracting Party's written request under
paragraph (2) has been submitted to the other Contracting Party and that other
Contracting Party has failed to appoint a designated representative.
(4) If the dispute cannot be resolved by informal dispute resolution, a formal dispute
resolution process will be followed.
(5) This Clause shall not constitute a waiver of either Contracting Party's right to institute
formal dispute resolution proceedings including litigation in order to avoid the expiration
of any applicable limitation periods.
(6) Each Contracting Party must, unless technically suspended according to
Clause III.1.2.2 paragraph (5), continue performing its obligations under the Agreement
while any dispute is being resolved informally, unless and until the Agreement is
terminated or in accordance with the final determination of the dispute resolution
procedure.
13
Section 2: Governance for the Annex
Clause III.2
(1) The list of referred documents in the Annex and the documents that are referred to in
the Annex may be amended by the body that has adopted the list or the respective
document, or by another body that is agreed by the eHN.
(2) Amendments of the list of referred documents in the Annex or of the documents that
are referred to in the Annex shall not be considered as an amendment of the Agreement.
(3) In case of contradiction between the Clauses of this Agreement and the provisions in
the documents listed in the Annex, the Clauses of this Agreement shall prevail.
Signed in , on in duplicate.
14
Annex
1. Guidelines on Electronic exchange of health data under the Cross-Border
Directive 2011/24/EU
2. Guideline on an Organisational Framework for eHealth National Contact
Point
3. Recommendations on Country Guide for eHealth NCP implementation
4. Policy paper on how to assess Member States’ overall readiness to go live
5. Policy Paper on assessment and decision procedures under CEF funding
6. eHealth-specific eID framework across-borders
7. Guideline on Interoperability of electronic professional registries
8. Governance model for the eHealth Digital Service Infrastructure during the
CEF funding
9. The Commitment of the European Commission to deliver the Core Services
for eHealth Digital Service Infrastructure
10. Rules of Procedures of the eHealth Network
15
Ref. Ares(2017)3033026 - 16/06/2017
eHealth Network
POLICY PAPER
on
eID specific framework for eHealth
RELEASE 1
eHealth Network
The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth. The Joint
Action supporting the eHealth Network (JAseHN) provides scientific and technical support to the
Network.
Adopted by consensus by the eHealth Network, Saint Julian's, Malta, 9 May 2017
2
eHealth Network
-Keep this page free-
3
eHealth Network
LIST OF ABBREVIATIONS
ACRONYM DEFINITION
CBeHIS Cross Border eHealth Information Services
CEF Connecting Europe Facility
DSI Digital Service Infrastructure
EC European Commission
eHDSI eHealth Digital Services Infrastructure
eHN eHealth Network
EIF European Interoperability Framework
eP electronic Prescription
EU European Union
IOP Interoperability
HP Health Professional
JAseHN Joint Action for support the eHN
LOST Legal, Organisational, Semantic, Technical
MLA/Agreement Agreement between National Authorities or National Organisations responsible
for National Contact Points for eHealth on the Criteria required for the
participation in Cross Border eHealth Information Services
former Multilateral Legal Agreement (MLA)
MS Member States (of EU)
NCP National Contact Point for cross border
NCPeH National Contact Point for eHealth
NI National Infrastructure
OFW Organisational Framework
OFW-NCPeH Organisational Framework for eHealth National Contact Point
PoC Point of Care
PS Patient Summary
ReEIF Refined eHealth European Interoperability Framework
QSCD Qualified Signature Creation Device
4
eHealth Network
TABLE OF CONTENTS
1. Introduction .......................................................................................................................................................... 6
1.1 Purpose of this document ................................................................................................................................. 6
1.2 Scope ..................................................................................................................................................................... 7
1.3 Objectives............................................................................................................................................................. 7
1.4 Initial considerations .......................................................................................................................................... 7
2. eID specific framework for eHealth...................................................................................................................... 8
2.1 The wider remit of eHealth eID ....................................................................................................................... 8
2.2 General Considerations, Responsibilities and Duties ................................................................................... 9
2.3 Legal Environment ...........................................................................................................................................10
2.4 Organisational and Policy Requirements ......................................................................................................11
2.5 Semantic Requirements ....................................................................................................................................12
2.6 Technical Requirements...................................................................................................................................13
3. Closing remarks ...................................................................................................................................................... 14
4. References ................................................................................................................................................................ 15
4.1 Legal references .................................................................................................................................................15
4.2 Content-related references ..............................................................................................................................16
5. Appendices .............................................................................................................................................................. 16
5.1 Definitions .........................................................................................................................................................16
5
eHealth Network
1. Introduction
One of the main challenges in supporting the eHN (eHealth Network) ambitions for sustainability
policies regarding assets in the field of eHealth cross-border interoperability is the bond between
policies and service provision by Member States (MS).
In order to establish the bond and allow it to grow and endure a set of simple but well-aligned
instruments needs to be prepared. One of the crucial instruments is an Organisational Framework
which describes, in a commonly understandable language, the principles and requirements for
National Contact Points for eHealth (NCPeH). Another important instrument is the eHealth-specific
eID framework across borders, which will address the mutual trust and recognition of means to
identify citizens (e.g. being a patient or a health care professional) using electronic cross-border
services under the Cross Border eHealth Information Services (CBeHIS). CBeHIS stands for the
infrastructure and the operations used to exchange real patient related data, in particular health data,
between its Members.
1.1 Purpose of this document
The purpose of this document is to propose an eID specific framework for eHealth to support the
establishment of an interoperable eID mechanism in MSs for the provision of Cross-Border eHealth
Information Services (CBeHIS). Introduction of the eID framework is to be done in two steps which
correspond to two releases. This document addresses only the first release of the eID framework.
The Policy Paper on the eID specific framework for eHealth was prepared based on accomplished
activities and in close alignment with still ongoing activities, namely (but non-exhaustively):
Organisational Framework for eHealth National Contact Points (OWA-NCPeH) adopted by
eHealth Network
Agreement between National Authorities or National Organisations responsible for National
Contact Points for eHealth on the Criteria required for the participation in Cross Border
eHealth Information Services (Agreement) to be adopted by eHealth Network and to be
signed by the competent national authorities.
eSENS’ T5.2 and eHealth eID Pilot through several Joint Workshops1
eSENS’ WP4 Implication of eIDAS Regulation for eHealth2
1An e-SENS JAseHN Joint Workshop took place on the 30th January 2017 in Berlin. At the end of that day the
open question remained how to make the NCPeH ready for eIDAS in time for eHDSI implementation (second
wave in February 2019).
The JAseHN eID Workshop on the 31st January 2017 tried to find a way forward concerning eID by sharing
expertise and sketching a composition of next steps on the basis of a common understanding. This resulted in a
revised concept and scope for D5.2.1 eID framework for eHealth which accounts for the joint assessment that an
interim solution for eID seems to be most appropriate. In the workshop strong concerns about the possibility to
finalize the eID framework in May 2017 were raised. Due to the complexity of the topic and the identified tasks
which have to be addressed but are mainly not in scope of JAseHN the participants of the workshop preferred to
have an eID framework with a provisional nature for eHealth Network meeting, which would be finalized at a later
stage for instance November 2017. This would also take into account the results of the identified tasks, which
should be done until then.
2 One view on the Implications of the eIDAS Regulation for eHealth is laid down in the eponymous document
from the legal expertise center of e-SENS, which was presented and discussed in the e-SENS JAseHN Joint
Workshop which took place on the 30th January 2017 in Berlin. Both parts of the eIDAS Regulation were equally
addressed in the document.
6
eHealth Network
1.2 Scope
The eID specific framework for eHealth lays down requirements to identify a patient and a health
professional in an interoperable manner by electronic means - considering the legal basis for CBeHIS
provision in Europe. It does not aim to alter already existing national eID solutions in eHealth, but to
provide Member States with viable aspects for future enhancements and strategic orientation.
The eID framework will help MSs to overcome the common challenges regarding electronic
identification, by providing a common approach to tackle this matter from a structural perspective as
well as framing a set of actions to leverage the joint adoption of this innovative instrument. Not in the
immediate focus of the eID framework but closely related and equally important is electronic
signature to name just one of the trust services under eIDAS Regulation. In short and only if
applicable the eID framework will take into account trust services as subordinated theme.
The eID specific framework for eHealth considers the current situation of eID, proposes a number of
actions and next steps and considers known concerns, challenges and, where applicable, provides
recommendations and requirements. It will show the boundaries of eID without limiting the scope of
technical options. The full eID framework will contain sustainable eID measures and requirements for
eID implementation in CBeHIS. The document at hand addresses the first release of the eID
framework with a second release planned for November 2017.
This eID framework will only consider and thus apply to the Patient Summary (PS) and
ePrescription/eDispensation (eP/eD) use case. However, specific adaptions of the framework for
additional use cases may be necessary at a later time.
1.3 Objectives
A plan for the revision of the eID framework is proposed and shall consist of the following releases:
Release 1 (Document at hand)
Provide an eID framework Release 1, which
lays down the past and current situation on eID in eHealth to build a common understanding
gives guidance on identification and authentication for the first wave of eHDSI and
frames a set of actions necessary for establishing an interoperable eHealth-specific eID
solution for CBeHIS.
Release 2 (in November 2017)
Provide an eID framework Release 2, which
adds concrete measures and requirements to be included in the eHDSI specifications for
March 2018 Release3 and
sets up sustainable principles and requirements for an interoperable eHealth-specific eID
solution for CBeHIS.
1.4 Initial considerations
The overall structure presented in the Guideline on an Organizational Framework for eHealth
National Contact Point (OFW-NCPeH) foresees several instruments to support CBeHIS in its
preparation, deployment and operation phase. Each Member State aiming to participate in the eHDSI
shall undergo all three phases. For every phase JAseHN provides supportive documents. The eID
specific framework for eHealth is one of these documents which in its Release 1 addresses the
Preparation and Deployment Phase.
3 This release is the basis for going live in February 2019 (second wave of CEF eHealth).
7
eHealth Network
The proposal for an eID specific framework for eHealth was designed in reference to the refined
eHealth European Interoperability Framework (reEIF).
2. eID specific framework for eHealth
The following sections lay down concerns, challenges and known possibilities or recommendations
regarding eID in eHealth taking into account the specific e-SENS recommendations. They are
structured following the LOST approach according to re EIF complemented by additional sections
where needed.
2.1 The wider remit of eHealth eID
At that time the epSOS pilot was implemented and operated not the eIDAS regulation but the e-
signature Directive 1999/93/EC applied and was hence taken into account by the epSOS
specifications and OpenNCP reference implementation. Changes to epSOS specifications or the
OpenNCP reference implementation are still made in order to maintain or to enhance the existing
content, e.g. for piloting purposes such as the e-SENS eHealth eID pilot.
Regulation (EU) N°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
(hereinafter the eIDAS Regulation) repealed the e-signature Directive 1999/93/EC and introduced
new concepts to build or strengthen trust in electronic transactions in the internal market. The
eIDAS regulation consists of two parts: one on Trust Services, the other on eIdentification. The
Trust Services part is already fully applicable whereas for the mandatory recognition of notified eID
Schemes there is a transition period until September 2018.
As of today there are no notified eID Schemes from Member States and specific information on their
notification plans are rare4. Due to a lack of experience it is also unclear how long the notification
process will take. Notification of an eID scheme comprises of several steps: Pre-notification by
submitting necessary materials for the notification, peer review of the to-be-notified eID scheme by
the other MSs and the formal step to publish the now notified eID scheme. A minimum time of six
months for the notification process is expected, yet it may take longer.
An eHealth eID Study should gain results based on an analysis of the Member States’ current and
planned use of the CEF eID building block under eIDAS for the eHDSI Patient Summary and
ePrescription services. It was contracted by DG SANTE and is produced by a Deloitte team in
cooperation with DG DIGIT. Within DG SANTE the eHDSI Solution Provider is the unit
responsible for the study. The study takes into account each national setup in terms of existing
systems and infrastructures for both national eID schemes and eHealth related ones as well as future
plans for notification under eIDAS of the following six MSs in an exemplary manner: Austria,
Finland, Italy, Luxembourg, Portugal and Sweden. On this basis future implementation scenarios of
cross-border identification/authentication of patients for eHealth should be identified and described.
eID of Health Professionals (HPs) are out of scope. A final draft version of the Deloitte Study on
eID in eHealth was shared in November, 2016; it is currently under revision and will be extended to
include additional MSs’ experience. To do so, several Member States received questionnaires on eID
regarding their specific national situation and whether the Member State considers one of the
described scenarios applicable for their national eID Implementation in CBeHIS.
4 At the time of the release of this document it was announced by the EC that Germany is the first MS starting the
notification process on 20th February 2017 for the German eID card and the electronic residence permit. Both eID
schemes do not apply to the eHealth domain. The German eID card is handed in general to a German citizen aged
16 or older, whereas the e-residence permit is given to nationals of non-EU countries with an existing residence
permit.
8
eHealth Network
Above mentioned scenarios draw on the very specific scenarios implemented by the e-SENS eID
eHealth Pilot under the vast resource and time restrictions of a non-operational EU pilot project. An
economic analysis of the chosen scenarios or an approach for a sustainable solution for eHDSI was
neither part of e-SENS nor done by Deloitte. Thus the economic impact of the proposed scenarios
or any additional scenarios beyond the scope of the study will need to be analysed in support of the
decision making in the Member States. For example, the cost per transaction may vary between some
Cents and several Euros.
The date of delivery for the final version of the study is end of April.
2.2 General Considerations, Responsibilities and Duties
eIDAS can be seen as a system and a tool box for establishing trust which sets new rules and
provides solutions not available at the time of epSOS. The epSOS specifications or the OpenNCP
reference implementation are not adapted for eIDAS as of today. This statement refers to both parts
of eIDAS: trust services as well as eIdentification. In order to bridge this gap and provide a
sustainable eID solution towards CBeHIS provision it is necessary to take a look at the following
general considerations especially towards responsibilities and duties of the diverse relevant actors.
eID eIDAS profile and the sample implementation of it called eIDAS-Node will be provided
by the European Commission trough DG DIGIT, specific national implementations will be
carried out by each national eIDAS competent authority. There is no correlation between the
notification of an eID Scheme and the existence of an eIDAS-Node implementation in MS.
MS will have an eIDAS-Node even if they do not intend to notify any eID Scheme in order
to be able to recognize the notified eID means of other MSs.
Due to the ongoing transition period until September 2018 for the mandatory recognition of
notified eID Schemes a stable release of the eID eIDAS profile and the eIDAS-Node will
only be finalized and published by DIGIT in the summer of 2018. Additional changes to and
releases of the eID eIDAS profile and the eIDAS-Node may happen afterwards but due to a
necessary rechecking and implementing processes in MS this will result in a service
suspension of approximately half a year. The eIDAS Cooperation Network as the highest
decision-taking body of eIDAS will enhance the adoption and operation of eIDAS regulation
with the eID eIDAS profile and the eIDAS-Node. It is up to DG SANTE and the eHealth
Network as equally positioned bodies to stand up aligned for the specific matters and
requirements of eHealth concerning especially data protection and identification of roles.
The solution provider of DG SANTE is the responsible unit for the eHDSI specifications
(based on the epSOS work) and the OpenNCP reference implementation of NCPeH.
Maintenance, updates and add-ons of the NCPeH take place under the guidance of DG
SANTE taking into account the specific DSI Owner’s perspective from a policy viewpoint.
The first wave of eHDSI (go live in February 2018) will operate without electronic
identification in practise. Patients and HPs will be identified and authenticated as described in
the epSOS use cases of PS and eP/eD5. For the second wave (go live in February 2019) and
onwards the sustainable eID solution will be available for the use of MS. However, MSs
remain free to decide if they will use identification and authentication with electronic or non-
electronic means. Electronic means hereby includes one of the options: notified or not
notified eID schemes. The Agreement between National Authorities or National
Organisations responsible for National Contact Points for eHealth on the Criteria required
for the participation in Cross Border eHealth Information Services (Agreement) is the basis
5 Further details are originally led out in epSOS Common Components Specifications (see
http://www.epsos.eu/uploads/tx_epsosfileshare/D3.4.2_epSOS_Common_Components_Specification_01.pdf)
but are outdated due to the NCPeH Release ‘Wave 1 – Release Candidate’, which was published on 28th March 2017
(see https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHDSI+Artefacts+Releases).
9
eHealth Network
for this (refer to Agreement clause II.1.1.2 on identification and authentication of patients,
health professionals and healthcare providers) clearly stating that the identification and
authentication of the HP and HCP is the responsibility of Country B, and is performed
according to national procedures (refer to Agreement clause II.1.1.3 Authorization of health
professionals).
2.3 Legal Environment
This section provides a non-exhaustive description of the legal environment on European level for
the eID framework.
The main foundation of the eID specific framework for eHealth is the eIDAS Regulation and the
General Data Protection Regulation, which applies to several domains, not specifically to eHealth.
The eIDAS Regulation and General Data Protection Regulation shall be followed by all Member
States and shall be transferred into national legislation regardless of whether they participate in
CBeHIS or not.
Here are significant aspects of the eIDAS regulation which are of special interest concerning eHealth:
It is entirely up to the Member States to decide if and which national eID system(s) will be
notified to the EC (compare Art. 7 as well as recitals 12 – 15 of the eIDAS regulation). However,
the recognition of notified eID schemes is mandatory from September 2018 on.
Processing of personal data is subject to the Directive 95/46/EC (compare recital 11 of the
eIDAS regulation and Art. 5 of the eIDAS regulation). The subsequent General Data Protection
Regulation should be taken into account as it repeals Directive 95/46/EC.
There is a description of assurance levels for electronic identification schemes; the mutual
recognition obligation (compare Art. 6 of the eIDAS regulation) is just given for assurance level
substantial/high (compare Art. 8 of the eIDAS regulation and its commission implementing
regulation 2015/1502/EU).
The eIDAS eID mechanisms and their specific regulatory, liability, IT security, trust
establishment, and operation environment provisions may impact the operation/fitness of
existing and new cross-border electronic services.
Repealing the eSignature Directive by eIDAS may impose new requirements (such as the
“qualified” property) onto existing and new cross-border electronic services.
Cooperation of Member States and interoperability of the notified electronic identification schemes
shall be facilitated e.g. by establishing an interoperability framework (compare Art. 12(7) of the
eIDAS regulation and its commission implementing decision 2015/296/EU and Art. 12(8) of the
eIDAS regulation and its commission implementing regulation 2015/1501/EU).
The recitals 10 and 12 of eIDAS explicitly state that the domain eHealth has been taken into
consideration. The eIDAS regulation applies for cross-border patient data exchange with online-
services such as Patient Summary and/or ePrescription services even though it is intended to serve
needs beyond domain boundaries. The eIDAS set-up allows for optional agreed extensions based on
the individual domain’s needs upon the domain’s request.
On the 27th of April 2016 the EC published a regulation on the protection of natural persons with
regard to the processing of personal data and on the free movement of such data, and repealing
Directive 95/46/EC (General Data Protection Regulation). The General Data Protection Regulation
made it explicitly clear that personal data concerning health and health care services as referred to in
the cross-border directive 2011/24/EU were taken into consideration, see recital 35.
The Agreement between National Authorities or National Organisations responsible for National
Contact Points for eHealth on the Criteria required for the participation in Cross Border eHealth
10
eHealth Network
Information Services (Agreement) is currently prepared by JAseHN task T6.2 and lays down legal
boundaries for the CBeHIS provision on the grounds of eIDAS regulation and several other
applicable laws. The agreement is to be adopted by the eHealth Network in May 2017 and to be
signed by the competent national authorities.
Among several other clauses the Agreement refers to the identification and authentication of patients,
health professionals and healthcare providers as well as to the authorization of a health professional.
These clauses on eID leave the decision to use electronic identification (notified under eIDAS or not
notified) or to use identification with non-electronic means with each Member State. A guidance
paper on eID will also be prepared by T6.2 but was not available at the time of writing.
The legal foundation of the eID specific framework for eHealth consists of eIDAS regulation, GDP
Regulation and Agreement. However, the overarching question which services of eIDAS (Trust
Services and eIdentification) will need to be used to reach the goal of secure data exchange across
borders still remains open.
To be able to come to an answer the following points need to be carefully considered:
Member States are obliged to recognize notified eID Schemes after September 2018 with a
transition period until then where recognition is on voluntary basis. There is no obligation for
Member States to notify eID Schemes neither now nor in the future. The consequences in
practical terms or interoperability of the large variety of possible implementations in MSs cannot
be foreseen at the moment.
Electronic signatures are now regulated under eIDAS (part on Trust Services) which repealed the
eSignature Directive 1999/93/EC and are to be implemented for the Patient Summary and
ePrescription/eDispensation use cases of CEF eHealth but new a new concept and consequently
new requirements have been introduced. They are to be analysed and further actions for
implementations initiated.
The Agreement prepared by the T6.2 of JAseHN states requirements to be fulfilled by eIDAS
Regulation and GDP Regulation (Agreement clause II.4.1). An according eHDSI implementation
and CBeHIS provision (“confidentiality, integrity, authenticity, availability and non-repudiation according to
Regulation 2014/910/EU and Regulation 2016/679/EU”) shall be analysed in order to incorporate
them not only on a technical level.
2.4 Organisational and Policy Requirements
Building on the legal environment the following organisational and policy related considerations and
requirements are identified.
The Agreement between National Authorities or National Organisations responsible for National
Contact Points for eHealth on the Criteria required for the participation in Cross Border eHealth
Information Services (Agreement) lays down the eHealth specific rules for cross-border patient data
exchange with online-services such as Patient Summary and/or ePrescription. For CBeHIS
implementation the following two requirements concerning the Agreement shall be fulfilled:
1) The eHealth Network shall adopt the Agreement between National Authorities or
National Organisations responsible for National Contact Points for eHealth on the
Criteria required for the participation in Cross Border eHealth Information Services
(Agreement).
2) Each National Authority responsible for the NCPeH and taking part in CBeHIS shall
sign the Agreement between National Authorities or National Organisations responsible
for National Contact Points for eHealth on the Criteria required for the participation in
Cross Border eHealth Information Services (Agreement).
11
eHealth Network
There is a need for specific requirements concerning ID for the first wave of eHDSI (go live in
February 2018) and afterwards.
3) The eHealth Network shall adopt that the first wave of eHDSI (go live in February 2018)
will operate patients’ and HPs’ identification and authentication non-electronically with
reference to the ‘Wave 1 – Operation Ready’ Release of the NCPeH6.
4) The eHealth Network shall adopt that from the second wave of eHDSI (go live in
February 2019) on patients’ and HPs’ identification and authentication will be operated
according to the clauses of the Agreement and the productive Releases of the NCPeH for
Wave 2 and following.
For cross-border purposes, a unique patient identifier is a necessary requirement for each individual
patient to be linked to the patient record in the country of affiliation. Additionally concerning eIDAS
assurance level the e-SENS project recommended:
“The eHealth Network should consider, in the relevant guidelines, appropriate assurance levels
for electronic identification and authentication for the purposes of cross border eHealth services
supported by the eHealth DSI balancing the risks associated to individual or groups of health
services and existing national laws and infrastructure capabilities.”
The following decisions of the eHealth Network have to be achieved in order to implement eID for
eHealth in MSs as part of CBeHIS.
5) The eHealth Network shall adopt common additional attributes7 for a patient identifier
in addition to the eIDAS minimum dataset according to 2015/1501/EU.
6) The eHealth Network shall adopt an agreed level of electronic identification and
authentication for CBeHIS.
The decision to be taken regarding adequate assurance level(s) appropriate for eHealth shall be strict
enough to fully protect medical data exchange (article 12 §3 and §7 of eIDAS). The decision could be
that only the highest assurance level of eIDAS would match the requirements to securely exchange
sensitive medical data across-borders. This would force each participating MS into strictly adhering to
the minimum requirements as assigned to the Assurance Level ‘high’ defined by the eIDAS
regulation. Each MS is requested to consider this carefully by investigating their national situation and
possible consequences to fulfil the minimum requirements of the highest eIDAS Assurance Level.
Additionally there is a need for a policy alignment concerning requirements on the interoperability of
electronic professional registries as laid down in the JAseHN guidelines.
7) The eHealth Network shall adopt the Guidelines on Interoperability of Electronic
Professional Registries.
2.5 Semantic Requirements
At the time of the release of this document no semantic requirements are known.
6 The NCPeH Release ‘Wave 1 – Operation Ready’ will be published by eHDSI Solution Provider 1 st of June 2017.
7 The inclusion and processing of additional attributes is in the MS responsibility. Nevertheless, to gain an
interoperable solution it is recommended that the highest decision making body of the respective domain (eHealth
network in case of eHealth) takes the decision and informs the eIDAS Cooperation Network accordingly. The latter
has to acknowledge the entire notified eID scheme of each MS including the additional attributes within the eIDAS
SAML Assertion at time of notification. Its use is optional by MS implementing CBeHIS. For more details refer to
section 2.6 Technical Requirements
12
eHealth Network
2.6 Technical Requirements
As of today the epSOS specifications and the OpenNCP reference implementation are not ready for
eIDAS. As recommended by e-SENS:
“It is proposed that a thorough review of the OpenNCP reference implementation is performed
in the light of the eIDAS Regulation and the tools it provides. The list of issues presented in this
document8, though not exhaustive, is indicative of the breadth of issues that need to be
examined.”
Technical consequences of eIDAS on CBeHIS have to be analysed in detail and taken into account
for the eID framework Release 2. Consequently epSOS specifications and the OpenNCP reference
implementation have to be updated accordingly to make the NCPeH ready for CBeHIS provision.
This above identified task also applies to Trust Services, which are not in the scope of JAseHN’s T5.2
eID for eHealth. If needed for CBeHIS, Trust Services shall be addressed through new activities as
lay out in section
3. Closing remarks.
The current eID eIDAS profile limits itself to the core requirements of eIDAS, while preserving a
certain degree of extensibility for the needs of other sectors such as encoding and transporting
additional attributes. This allows domains some governance over domain-specific needs, without
changing the eID eIDAS profile and its sample implementation called eIDAS-Node. From the
eHealth perspective it is currently unclear how feasible and sustainable in the medium/long-term a
solution can be which solely relies on the eID eIDAS profile and eIDAS-Node, under use of only
additional (optional) attributes.
The eID aspects of the services Patient Summary and ePrescription/eDispensation are addressed in
the EU-project e-SENS9 and there in WP5.2 which is in charge of the eHealth pilot10. The e-SENS
eHealth eID architecture describes two suitable technical solutions for eID. One focuses on a strictly
smartcard-based approach as a qualified signature creation device (QSCD) in conjunction with the
contained qualified certificates, which essentially consolidates the diverging smartcard eID means of
different MS into one streamlined solution. QSCD and qualified certificates are also specified and
ruled by the eIDAS Regulation and are primarily meant to be used for creation of electronic
signatures, and not for authentication. The other approach focuses on virtual authentication schemes
(such as eIDAS, legacy STORK 2.0, etc.) as well as an optional mobile eID, which is feasible for MSs
with a software token-based (non-physical eID carrier) eID solution. Both solutions are fully
compatible and enable seamless identification and authentication of patients and health professionals.
8 eSENS’s WP4 Implication of eIDAS Regulation for eHealth
9 The aim of the e-SENS project is to facilitate the deployment of cross-border digital public services through
generic and re-usable technical components, based on the building blocks of the Large Scale Pilots. The
consolidated technical solutions, with a strong focus on e-ID, e-Documents, e-Delivery, Semantics and e-Signatures,
aim to provide the foundation for a platform of “core services” for the eGovernment cross-border digital
infrastructure foreseen in the regulation for implementing the Connecting Europe Facility (CEF).
10 e-SENS is currently carrying out an eHealth eID Pilot with Austria, Greece, Italy, Portugal and Spain participating
in it, which will bring up more detailed results and experiences on technical level. This enhances eID specific
framework for eHealth with aspects on readiness and maturity of the e-SENS technical solutions as well as lessons
learned concerning future implementations and long-term sustainability. The eHealth eID Pilot is expected to end in
the first quarter of 2017.
13
eHealth Network
However, any combined approach with eIDAS eID requires the capability to encode and transport
an additional attribute11 patient identifier. This attribute will be added to the eIDAS SAML Assertion
outside of the eIDAS minimum data set12, while the minimum dataset remains unchanged.
The inclusion and processing of additional attributes is in the MS responsibility. Nevertheless, to gain
an interoperable solution it is recommended that the highest decision making body of the respective
domain takes the decision and informs the eIDAS Cooperation Network accordingly. The latter has
to acknowledge the entire notified eID scheme of each MS including the additional attributes within
the eIDAS SAML Assertion at time of notification.
However, it remains to be the responsibility of the eHealth Network to take the required decision
(see recommendation #5) and take together with the European Commission immediate action to
ensure that the eIDAS technical subgroup and the eIDAS Cooperation Network will add the patient
identifier attribute outside of the eIDAS minimum data set as a domain specific attribute. Its use is
optional by MS implementing CBeHIS.
8) Each Member State participating in CBeHIS shall use the agreed additional attribute(s)
for patient identifier in addition to the eIDAS minimum dataset according to
2015/1501/EU if applicable for its national implementation.
9) Each Member State participating in CBeHIS shall implement the agreed level of
electronic identification and authentication for CBeHIS.
Each Member State is responsible to set up and maintain electronic register(s) of health professionals
according to the adopted guidelines on the interoperability of electronic Professional Registries.
10) Each Member State participating in CBeHIS shall implement electronic register(s) of
health professionals according to the Guidelines on Interoperability of electronic
Professional Registries.
11) Each Member State participating in CBeHIS shall maintain electronic register(s) of
health professionals.
For an unequivocal identification of healthcare professionals a registration with at least one national
healthcare professional organisation or health authority is required. A possibility to check the
attributes of the data requester needs to be provided as well.
3. Closing remarks
The present document outlines the first release of the eID specific framework for eHealth and
lays down the past and current situation on eID in eHealth to build a common
understanding,
gives guidance on identification and authentication for the first wave of eHDSI and
frames a set of actions necessary for establishing an interoperable eHealth-specific eID
solution for CBeHIS.
The proposed eID specific framework for eHealth shall be revised and enhanced as necessary, taking
into consideration the lessons learnt and experience gained from the emergence of CBeHIS. A way
forward for the revision of the eID framework was proposed and shall be followed to establish
interoperable eID measures and implementation in CBeHIS.
11 No additional attribute is needed for MS that merged the eGovernment and patient identifier into one singular
property (such as PT, IT, etc.). Consequently the use of it will remain optional depending on the MS’s decision.
12 Sector specific attributes can be added under 2.7 Sector Specific Attributes of eIDAS SAML Attribute Profile v1.1
and future versions.
14
eHealth Network
In order to successfully create the eID framework in its full version the following tasks were
identified by JAseHN and e-SENS along with a proposal who should address those:
Technical analysis of the NCPeH (epSOS specifications and OpenNCP reference
implementation). This task should be carried out by eHDSI Solution Provider. Results are
needed in order to provide the Release 2 of the eID framework.
Economic analysis of eID implementation scenarios (this includes the Deloitte scenarios but
is not limited to). This task should be carried out by eHDSI Owner giving further guidance to
the eHealth Network and the eHMSEG.
Results of both analyses need to be incorporated into the eID framework for eHealth Release
2. This is the task of JAseHN T5.2 to be done until November 2017. To meet this deadline
the tasks is currently preparing a proposal for subcontracting as discussed in the JAseHN
workshop.
Requirements of eID framework for eHealth Release 2 need to be implemented into epSOS
specifications and OpenNCP reference implementation. This task should be carried out by
eHDSI Solution Provider and become a part of the March 2018 Release of the epSOS
specifications and OpenNCP reference implementation.
epSOS specifications and OpenNCP reference implementation have to be aligned with eID
eIDAS profile and sample implementation called eIDAS-Node especially for but not limited
to eID. This task should be carried out by eHDSI Solution Provider in collaboration with
DG DIGIT in order to cater for needs of the eHealth domain on eID and consider those in
the summer release of the eID eIDAS profile and its sample implementation. This has to be
done in alignment with the eIDAS Cooperation Network.
Requirements concerning Trust Services needs to be addressed for CBeHIS provision. This
task should be carried out by eHDSI owner and eHDSI Solution Provider in collaboration
with eHMSEG in order to reach an aligned understanding on Trust Services in CBeHIS and
agree on the next steps towards the definition of requirements.
4. References
4.1 Legal references
2011/24/EU directive on the application of patients’ rights in cross-border healthcare (cross-
border directive)
2014/910/EU regulation on the electronic identification and trust services for electronic
transactions in the internal market (eIDAS regulation) and delegated acts
2015/296/EU Commission implementing decision establishing procedural arrangements for
cooperation between Member States on electronic identification pursuant to Article 12(7) of
eIDAS regulation
2015/1501/EU Commission implementing regulation on the interoperability framework
pursuant to Article 12(8) of eIDAS regulation
2015/1502/EU Commission implementing regulation on setting out minimum technical
specifications and procedures for assurance levels for electronic identification means pursuant
to Article 8(3) of eIDAS regulation
95/46/EU directive on the protection of individuals with regard to the processing of
personal data and on the free movement of such data
2016/679/EU regulation on the protection of natural persons with regard to the processing
of personal data and the free movement of such data (General Data Protection Regulation)
15
eHealth Network
4.2 Content-related references
eHealth Network documents
o Organisational Framework for eHealth National Contact Points (OWA-NCPeH)
o General Guidelines on electronic exchange of health data under cross-border Directive
2011/24/EU (Release 2)
o Guideline on Patient Summary for unscheduled care (Release 2)
o Guideline on ePrescription and eDispensation (Release 2)
o Agreement between National Authorities or National Organisations responsible for
National Contact Points for eHealth on the Criteria required for the participation in
Cross Border eHealth Information Services (Agreement)
o eID for eHealth: towards EU governance
o eID for eHealth: towards coherence with the proposal of the Commission for eID
regulation
e-SENS documents
o WP5.2 eID general architecture
o WP5.2 eID eIDAS Integration Approach: e-SENS eHealth eID with eIDAS Approach
and Pilot (work in progress)
o WP4 Implication of eIDAS Regulation for eHealth (final draft available)
epSOS documents
o WP3.4 epSOS Common Components Specifications
NCPeH Release
o Wave 1 – Release Candidate [W1-RC]
o Wave 1 – Operation Ready (to be published by 1st June 2017)
Deloitte eHealth eID Study ‘The use of CEF eID in the CEF eHealth DSI’ Draft Report
V2.0
5. Appendices
5.1 Definitions
CONCEPT DEFINITION
CBeHIS The generic services are the necessary implementation of data exchange at
country level, the core services at EU level. These together enable the provision
of Cross Border eHealth Information Services (CBeHIS).
CEF eHealth DSI is the initial deployment and operation of services for cross-border health data
exchange under the Connecting Europe Facility (CEF). eHDSI sets up and starts
deploying the core and generic services, as defined in the CEF, for Patient
Summary and ePrescription.
Communication MS system that manages CBeHIS transactions with other MS and which connects
Gateway to the NI.
It is an entry/exit point from the MS, acting on behalf of a HP and citizen (at a
Point of Care) that assures the exchange of patient’s medical data in a controlled
environment.
Compliance A well-defined set of activities and evidences used to ensure that NCPeH
Establishment compliance can be established, maintained and reinforced
Process
Country A The country of affiliation. This is the country that holds information about a
16
eHealth Network
patient, where the patient can be univocally identified and his data may be
accessed.
Country B The country of treatment i.e. where cross-border health care is provided when the
patient is seeking care abroad.
eIDAS The eIDAS Cooperation Network, which was created by the Commission
Cooperation Decision EU 2015/296 implementing the eIDAS Regulation, is one of the main
Network tools of cooperation between the Member States in the area of electronic
identification (eID) in order to achieve interoperability and security of their eID
schemes. It provides a forum with regular meetings, where Member States can
exchange relevant information, experience and good practice.
eHDSI Owner eHDSI Owner (DG SANTE Unit B3) is responsible for overall policy planning
and coordination for eHDSI (prepare the meetings of the eHealth Network and
support its work, and ensure the liaison between the eHealth Network, eHDSI IT
governance and various Commission services.
eHDSI Solution eHDSI Solution Provider (DG SANTE Unit A4) is responsible for the provision
Provider of core services (to build the eHDSI specific software and services; advise and
assist Member States on setting up the generic services, and ensure that they are
linked to the core services (technical and semantic interoperability)). The DSI
Solution Provider for Building Block services (eID, eDelivery ...) to the eHealth
domain is DG DIGIT (A3, B4).
Framework Is a real or conceptual structure intended to serve as a support or guide for the
building of something that expands the structure into something useful.
Guideline A suggested way of compliance when doing something. It is visible to those using
or supporting the use of a particular service but there are no sanctions if not
followed.
Guideline for Intended to present to the eHealth Network’s members a clear guideline with the
Adoption intention for it to be adopted and optionally implemented by the EU MS at
national level in the next step.
National The healthcare IT infrastructure, which manages patient and HP/HCP13
Infrastructure identification and health care records in MS
NCP National Contact Point as referred in Article 6 of the 2011/24/EU Directive
NCPeH National Contact Point for eHealth, that may act as an organization and technical
gateway for the provision of eHealth Cross-Border Information Services
NCPeH Set of activities aiming to evidence the NCPeH compliance with the full range of
Deployment requirements (LOST) established towards CBeHIS provision
NCPeH Process of Prepare, Deploy and Operate a NCPeH
Implementation
NCPeH Operation Set of activities performed by the MS while providing the service to the citizens
and health professionals
NCPeH Set of activities aiming to set up an NCPeH
13 see Article 3 (f) and (g) of Directive 2011/24/EU
17
eHealth Network
Preparation
Organisational Define core characteristics, duties and responsibilities of a NCPeH
Framework
PoC A Point of Contact is a location where an EU citizen may seek healthcare
services. It can be a hospital, a pharmacy or any other point of the healthcare
system of Country B.
Requirement Definition of relevant needs (business, functional, non-functional, technical and
technological) for system specification and implementation
18
Ref. Ares(2017)3033026 - 16/06/2017
eHealth Network
eHealth Network
Governance model for the eHealth Digital Service
Infrastructure during the CEF funding
Updated version 2016
1
eHealth Network
The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth. The Joint
Action supporting the eHealth Network (JAseHN) provides scientific and technical support to the
Network.
Adopted by the eHealth Network, Brussels, 21 November 2016
2
eHealth Network
-Keep this page free-
3
eHealth Network
Introduction
The eHealth Digital Service Infrastructure (eHDSI or eHealth DSI) is the initial deployment and
operation of services for cross-border health data exchange under the Connecting Europe
Facility (CEF). eHDSI sets up and starts deploying the core and generic services, as defined in the
CEF, for Patient Summary and ePrescription. The generic services are the necessary
implementation of data exchange at country level, the core services at EU level1. These together
enable the provision of Cross Border eHealth Information Services2 (CBeHIS).
The eHDSI is financed by the Member States and the European Union through the CEF
programme. The core services are set-up and deployed by the European Commission using its
own resources and through calls for tender financed by CEF. The generic services are funded
from the national sources and supported by grants from the CEF through a call for proposals.
The grant agreements for generic services will be managed by Innovation and Networking
Executive Agency (INEA).
The 2015 work programme3 of CEF defines Patient Summary and ePrescription/eDispensation as
the scope of the eHDSI, the amendment added the core services of European Reference
Networks. The duration of action is 4 years (2015–2019). Future calls are expected in 2017 and
possibly later during the duration of the CEF programme until 2020.
The provision of generic services in the Member State under the eHDSI means the preparation,
setting-up, deployment and operations of the National Contact Point for eHealth (NCPeH) for
provision of CBeHIS. A national or regional network connecting a wide range of healthcare
providers to each other is a prerequisite for connecting them to a European network through
the NCPeH.
The governance and operating principles of the NCPeHs are covered in the Guideline4 on an
Organisational Framework for eHealth National Contact Point adopted by the eHealth Network.
Need for robust governance of the eHDSI
The eHDSI needs a robust governance model to succeed as a health policy and initial
deployment and operation of service. The governance also needs to assure an overall coherence
of the European Interoperability ecosystem5 which is being built.
epSOS was a large-scale research and development project under 7th Framework Programme,
with an appropriate project organisation. The project exchanged a limited amount of test data.
1
The CEF Telecom guidelines define digital service infrastructures (DSIs), which are composed of ‘core service
platforms’ – central hubs which enable trans-European connectivity – and ‘generic services’ which link national
infrastructures to the core service platforms. ‘Building blocks’ are basic DSIs which enable the more complex
digital service infrastructures to function properly.
2
http://ec.europa.eu/health/ehealth/docs/ev_20151123_co01_en.pdf
3
Amended CEF 2015 Work Programme is here:
https://ec.europa.eu/inea/sites/inea/files/c_2015_7381_f1_annex_en_v3_p1_828057_cef_telecom.pdf
4
http://ec.europa.eu/health/ehealth/docs/ev_20151123_co01_en.pdf
5
http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ%3AJOL_2014_086_R_0014_01&from=EN
4
eHealth Network
The eHDSI is a move from a project to deployment phase of cross-border exchange of health
data (CBeHIS). A new governance model is needed, which has strong steering elements
addressing both policy and technical issues.
When real patient data is exchanged, the NCPeH must be in conformity with the agreed
principles as adopted by the eHealth Network (eHN). These principles include - but are not
limited to - the Guidelines for an Organisational Framework of National Contact Point for
eHealth6 , the future agreement between National Authorities responsible for National Contact
Points for eHealth on participation in cross-border eHealth information services7, and Guidelines
on Patient Summary and ePrescription.
The eHDSI stage is expected to last at least until 2019. The governance structure as presented in
this document will be in operation during the financing and deployment of the NCPeHs under
CEF.
It is expected that towards 2019, the EU’s cross-border health data exchange starts to be an
accepted practice of the national healthcare systems and that an increase in the patients served
by the CBeHIS will be noticed. At that stage, the building up phase of core services is over and
many countries have their NCPeH in routine operation, as well some groups of countries show a
routine exchange of patient data. This coincides with the finishing of the first CEF funding round
for generic services.
Beyond 2020, a new, permanent governance structure is needed for operation and maintenance
of CBeHIS.
The permanent governance model is outside the scope of this document.
The European Reference Networks (ERN) will have their governance structures. However, the
CEF financing will be under the umbrella of the eHDSI. Many legal, organisational, semantic and
technical issues of eHDSI will be the same. The ERNs are in the building phase and the links of
eHDSI-ERN to the eHDSI-PS/eP are still unclear and needs to be considered in the near future. At
national level the NCPeH may have a role, and at EU level the eHealth Network may get involved
in policy decisions.
The governance of the eHDSI-ERN is outside the scope of this document.
Review of the document
The eHDSI governance model, as presented in this document, was originally adopted by the
eHealth Network on 23 November 2015, [and revised on 21 November 2016]. It can be subject
to revision if needed by the eHN.
6
http://ec.europa.eu/health/ehealth/docs/ev_20151123_co01_en.pdf
7
Under discussion the eHealth Network, scheduled for adoption in June 2017
5
eHealth Network
Key elements of the governance model
The governance model presented in this document stems from the general CEF governance
model8. This document adds the ehealth policy structures and adapts the CEF model to the
specificities of the health sector taking into account existing actors, structures and bodies.
The eHDSI governance model consists of bodies dealing with
- Policy governance
- IT governance
- Secretariat functions
- Stakeholder liaison
The governance model seeks not to set up new structures but associate the eHDSI tasks to
existing bodies to the extent possible.
An audit function is necessary to ensure that NCPeH compliance can be established, maintained
and reinforced. The audit process is as described in Section 4.1 of the Guidelines for an
Organisational Framework of National Contact Point for eHealth9.
The organisation of the audit is outside the scope of this document.
8
Non-paper on the IT Governance of CEF Building Block Digital Service Infrastructures (DSIs). See here. The
governance model is based on The European Commission PM2 Project Management Methodology Guide 2.5
Edition.
9
http://ec.europa.eu/health/ehealth/docs/ev_20151123_co01_en.pdf
6
eHealth Network
Description of governance bodies and functions
Policy governance bodies and secretariat
Governance body or function Who is involved?
eHealth Policy Owner eHealth Network, as set up by Directive 2011/24/EU
eHealth Policy Secretariat European Commission, DG SANTE (B3)
Member States Policy Support Through appropriate Joint Action10 Work Packages,
such as JAseHN WP 5 Interoperability and
Standardisation; Task 5.5 Semantic Interoperability;
Task 5.6 CEF Operational Support; Task 6.2 Legal
Interoperability.
IT governance bodies and secretariat functions
Governance function or body Who is involved?
DSI Owner SANTE (Directorate B)
DSI Co-Owner CNECT (Directorate H)
Operational Management Board DG SANTE (B3, A4), CNECT (H3), DIGIT
Chair and co-chairs of eHMSEG
Member States Expert Group Managers responsible for implementing the eHealth
National Contact Point, nominated by the
participating MS.
DSI Solution Provider SANTE (A4), DIGIT (A3, B4)
Member States Operational Support National Contact Points for eHealth in view of their
responsibility for contribution towards the eHDSI at
EU level, through the community set up in the
eHDSI.
10
“Joint action” in this document refers to the Joint Action supporting the eHealth Network (JAseHN) running
2015-2018, or possible later joint actions working towards similar aims.
7
eHealth Network
Stakeholder liaison
Who is involved? Liaison modality
Patient, professional, industry and other Mediated by Commission through the eHealth
stakeholders Stakeholders Group.
Stakeholders take part in joint action processes
according to agreed principles.
Standardisation bodies [To be decided – Could be mediated by JAseHN
through its Standardisation Platform if set up.]
DSI community Liaison with OpenNCP community through SANTE A4
Interaction processes between the eHDSI governance bodies
The eHDSI governance bodies strive at the full transparency in their operations, for example by
circulating or publishing the minutes of their meetings and reporting to each other actively.
The eHDSI governance bodies will invite experts to attend the meetings when beneficial for the
handling of the matters being discussed. .
The work plans and other decisions will define in more detail the business relationships and the
division of development, implementation and operational tasks between the various eHDSI bodies,
within the framework of this decision.
The composition and tasks of the main bodies in the eHDSI governance
eHealth Policy Owner - the eHealth Network
Main function: The eHealth Network steers the policy relevant to the DSI. It is assisted by the Joint
Action supporting the eHealth Network (JAseHN).
Tasks
1. Set the priorities of the eHDSI, and oversee its operation. Decide on guidelines for the
operation of the eHDSI and the strategy on standards used.
2. Seek and ensure funding for the eHDSI and its future components
3. Consider solutions for legal issues.
4. Admit11 the National Contact Points to become operational in CBeHIS
5. Approve the annual work plan and financial plan for the eHDSI.
Composed of: Representatives of Member States
11
The decision to admit a Member State NCPeH could be taken by the participating members alone. However,
during eHDSI, the broad consensus and transparency on the joining is important and the decision should be
taken in full transparency involving the all Members of the eHealth network, keeping in mind that all Member
States are also prospective members in the CBeHIS and thus have an interest.
8
eHealth Network
Chaired by: Co-Chairs of the Network (Director General of DG SANTE and a Member
State representative)
Secretariat: eHealth Policy Secretariat
Meeting frequency: Twice a year
eHealth Policy Secretariat - European Commission, DG SANTE Unit B3
Main function: To prepare the meetings of the eHealth Network and support its work, and ensure
the liaison between the eHealth Network, eHDSI IT governance and various Commission services.
Tasks
1. Overall policy planning and coordination for eHDSI
2. Contacts with CNECT on the CEF Work Programme preparation, budget and liaison with the
CEF Telecom Committee.
3. Prepare the eHDSI-related topics for the eHealth Network.
4. Liaison with the joint action assisting the eHealth Network.
5. Work closely with the DSI Solution Provider in preparing the meetings of eHMSEG and
eHOMB.
6. Supports eHOMB and eHMSEG with their necessary interactions and communication.
Team Leader: Head of Unit SANTE B3
Team: Staff in SANTE B3
eHealth Operational Management Board (eHOMB)
Main function: To oversee the provision of service, make tactical and operational decisions about
the eHDSI, and coordinate with other DSIs. Oversee the building of core elements and maintain the
close links to Member States and NCPeH. It reports to the eHealth Network and the Member State
Expert Group.
Tasks according to the IT governance processes:
1. Lifecycle management. Management of the lifecycle of software and services: changes,
releases. Create a Service Level Agreement with DSI Solution Provider.
2. Architecture management. Management of the DSI's architecture
3. Risk and issue management. Management of risks, opportunities and issues
4. Configuration management. Track configuration of software and services
5. Propose the annual work plan and financial plan to the eHealth Network.
6. MS and stakeholders liaison. Management of the consultations of Member States and
stakeholders
7. Reporting and escalation. Report to the CEF in view of it monitoring the progress of the
eHDSI.
Composed of: DSI Owner and Co-owner
eHealth Solution Provider
Core Building Blocks Solution Provider
Chair and Co-Chairs of the eHealth Member States Expert Group
Chaired by: DSI Owner
Meeting frequency: 4-8 times a year depending on the need
9
eHealth Network
eHDSI Member States Expert Group (eHMSEG)
eHMSEG is a group representing the participating Member States12. eHMSEG coordinates the
technical and organisational implementation of the NCPeH to ensure that they are fully
interoperable. It gives advice to the eHealth Network and eHOMB on core elements and provides a
link to building of the national elements. eHMSEG is duly informed about and consulted on solutions
for the eHDSI, and asked to contribute to the lifecycle of the eHDSI's core services.
It can set up working groups composed of its members and (external) experts on specific topics. The
eHDSI Solution Provider will support the working groups. Working groups report to the eHMSEG and
interact with the Solution Provider.
Tasks
1. Provide assistance and expert advice on:
a. The management of the lifecycle of the DSI's software and services.
b. The management of risks and opportunities, including existing or emerging service
management issues, that affect the DSI;
c. The definition of architecture guidelines for the DSI
d. Consult with the joint action and its WP leaders as appropriate.
2. Monitor and support the national implementation, such as:
a. Compliance with legal agreements and provisions in force;
b. Compliance with agreed technical solutions and specifications, in line with the
guidelines adopted by the eHealth Network;
c. Address semantic issues relates to the use of terminologies and national
translations.
3. Evaluate the initial audit13 report of a National Contact Point and prepare a proposal for
admission to the eHN, and prepare a proposal for follow up of subsequent follow-up audits,
in agreement with the DSI Owner.
4. Report to the eHealth Network on the eHDSI.
5. Initiate further activities or interactions in order to foster cooperation of Member State in
preparations, implementation and operations of the eHDSI.
Composed of: Managers responsible for implementing the NCPeH, nominated by the
participating MSs
Chaired by: Chair and two Co-Chairs elected from the Member State representatives
Secretariat: eHealth Solution Provider, jointly with the eHealth Policy Secretariat
Meeting frequency: On average 4 times per year
12
The participating Member States are those, who express their intention to join the permanent CBeHIS and
the network being built through the eHDSI. They thus join the Expert Group and participate in the deployment
and operation in the CBeHIS. Normally this means also participation in the call for the CEF funding for the
generic services.
13
The framework for conducting the initial and follow-up audits will be decided by the eHealth Network.
10
eHealth Network
eHealth DSI Solution Provider - European Commission, DG SANTE Unit A4
Main function: To build the eHealth DSI specific software and services; advise and assist Member
States on setting up the generic services, and ensure that they are linked to the core services
(technical and semantic interoperability). eHealth DSI Solution Provider is responsible for the
provision of core services.
Tasks
1. Technical planning and programming of the DSI's software and services
2. Implement the eHealth specific building blocks according to a Service Level Agreement
3. Liaison with DIGIT on core DSI building blocks
4. Manage contracting for core eHealth building blocks and contribute to the calls for
proposals on generic services
5. Prepare and organise the meetings of eHOMB and eHMSEG
6. Coordinates the activities of the OpenNCP Community
Team Leader: Head of Unit SANTE A4
Team: eHDSI project manager and other IT staff in A4
The DSI Solution Provider for Building Block services (eID, eDelivery…) to the eHealth domain is
DIGIT.
DSI community - Open NCP Community
The open NCP community is coordinated by the DSI solution provider and it is composed of
developers from DSI solution provider, the Member States and private companies. The OpenNCP
community implements technically the decisions made by the Operational Management board
related to the DSI's software and services.
Liaison with patient, professional, industry and other stakeholders
The liaison is mediated by Commission through the eHealth Stakeholders Group and stakeholders
take part in JAseHN processes according to agreed principles.
The exchange and input will be through different levels, eHealth Network and its operational arm
JAseHN as well as through the Expert group and Operational Management Board.
Liaison is supported by the eHealth Policy Secretariat.
Liaison with standardisation bodies
eHDSI needs to maintain liaison with the standardisation bodies, such as the Multi-Stakeholder
Platform on ICT standardisation, and other structures active in standardisation in eHealth.
[The arrangements in JAseHN to be decided.]
11
Ref.
Ref.Ares(2017)3033026
Ares(2017)853029 - 16/06/2017
16/02/2017
EUROPEAN COMMISSION
DIRECTORATE-GENERAL FOR HEALTH AND FOOD SAFETY
Health systems, medical products and innovation
Director
Brussels, 16 February 2017
SANTE B
Chair of the eHealth Member States Expert Group
Prof. Henrique Gil Martins
By email
The Commitment of the European Commission to deliver the Core Services
for eHealth Digital Service Infrastructure
Dear Mr Martins,
The Connecting Europe Facility (CEF) supports basic and reusable digital services, as
well as more complex digital services. These building blocks can be combined with each
other and integrated with more complex services. The CEF is implemented via annual
Work Programmes, identifying the priorities and the actions to be launched during the
year.
The guidelines for trans-European networks in the area of telecommunications
infrastructure (2014) define ‘core service platforms’ – central hubs which enable trans-
European connectivity – and ‘generic services’ which link national infrastructures to the
core service platforms.
Core Services are implemented primarily by the European Commission. The Solution
Provider’s main function is to build the eHealth DSI specific software and services;
advise and assist Member States on setting up the generic services, and ensure that they
are linked to the core services (technical and semantic interoperability).
The eHealth DSI Solution Provider is responsible for the provision of core services.
The eHDSI Solution Provider is committed to deliver appropriate Core Services and it
proposes an annual work plan to the eHealth Network, after consulting the eHealth
Member State Expert Group.
To make the process of development transparent for the Member States, the eHDSI
Solution Provider prepares a monthly Status Progress Report, reports to the eHealth
Operational Management Board meetings and eHealth Member States Expert Group.
Member States are invited to advise and make recommendations based on the Reports.
Commission européenne/Europese Commissie, 1049 Bruxelles/Brussel, BELGIQUE/BELGIË - Tel. +32 22991111
Office: B232 08/134
[email protected]
Generic services are implemented and run by the legal entities supported by the national
authority responsible for eHealth who applied and were granted the funding within the
relevant CEF Work Programme calls.
With the signature of the Grant Agreement under the Connecting Europe Facility (CEF)
– Telecommunications sector, the beneficiaries accept the grant and agree to implement
the action, acting on their own responsibility. Article II.14 (force majeure) in the
Agreement regulates the procedure when any unforeseeable exceptional situation or
event beyond the parties' control occurs, which prevents either of them from fulfilling
any of their obligations under the Agreement, such as the failure of the Solution Provider
to deliver on its commitments.
With this letter, I would like to communicate to you the Solution Provider’s commitment,
which aims at delivering eHealth DSI Core Services according to the release delivery
plan in the Annex.
[Signed electronically]
Andrzej Rys
Director,
Chair of the eHealth Operational
Management Board
Annex
2
Annex. The Solution Provider work efforts and commitment aim at delivering eHealth
DSI Core Services according to the following release delivery plan:
ID MILESTONE DUE DATE
1st RELEASE Cycle
01 Communication Services Go Live - Release 1 2016-03
02 Collaboration Services Go Live - Release 1 2016-11
03 1st eHDSI OpenNCP Boot Camp 2017-01
04 Communication Services Go Live - Release 2 2017-03
05 Interoperability Specifications - Release 1 2017-03
06 Configuration Services Go Live - Release 1 2017-03
07 Terminology Services Go Live - Release 1 2017-03
08 NCPeH reference Implementation Operation ready release (V2.5.x) 2017-06
09 1st eHealth Interoperability Test marathon at EC 2017-09
10 Completion of the Audit for MS Going live in Wave 1 2017-10
11 Approval decision for Wave 1 of NCPeH Go Live 2017-11
12 Wave 1 of NCPeH Go Live 2018-02
2nd RELEASE Cycle
13 Communication Services Go Live - Release 3 2018-03
14 Collaboration Services Go Live – Release 2 2018-03
15 Interoperability Specifications – Release 2 2018-03
16 Configuration Services Go Live – Release 2 2018-03
17 Terminology Services Go Live – Release 2 2018-03
18 NCPeH reference Implementation Operation ready release (V3.0.x) 2018-03
19 2nd eHealth Interoperability Test marathon at EC 2018-09
20 Completion of the Audit for MS Going live in Wave 2 2018-10
21 Approval decision for Wave 1 of NCPeH Go Live 2018-11
22 Wave 2 of NCPeH Go Live 2019-02
3rd RELEASE Cycle
23 Communication Services Go Live - Release 4 2019-03
24 Collaboration Services Go Live – Release 3 2019-03
25 Interoperability Specifications – Release 3 2019-03
26 Configuration Services Go Live – Release 3 2019-03
3
27 Terminology Services Go Live – Release 3 2019-03
28 NCPeH reference Implementation Operation ready release (V3.1.x) 2019-03
29 3rd eHealth Interoperability Test marathon at EC 2019-09
30 Completion of the Audit for MS Going live in Wave 3 2019-10
31 Approval decision for Wave 1 of NCPeH Go Live 2019-11
32 Wave 3 of NCPeH Go Live 2020-02
4th RELEASE Cycle
33 Communication Services Go Live - Release 5 2020-03
34 Collaboration Services Go Live - Release 4 2020-03
35 Interoperability Specifications - Release 4 2020-03
36 Configuration Services Go Live - Release 4 2020-03
37 Terminology Services Go Live - Release 4 2020-03
38 NCPeH reference Implementation Operation ready release (V3.2.x) 2020-03
4
Electronically signed on 16/02/2017 09:28 (UTC+01) in accordance with article 4.2 (Validity of electronic documents) of Commission Decision 2004/563
Ref. Ares(2012)528602
Ref. Ares(2017)3033026- -27/04/2012
16/06/2017
EUROPEAN COMMISSION
HEALTH AND CONSUMERS DIRECTORATE-GENERAL
Health systems and products
Healthcare systems
RULES OF PROCEDURES OF THE eHEALTH NETWORK
The eHealth Network,
Having regard to 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, and in particular
to Article 14 and to Recital 56 thereof,
Having regard to Commission Implementing Decision 2011/890/EU of 22 December 2011
providing the rules for the establishment, the management and the functioning of the Network
of national competent authorities on eHealth [Hereinafter 'the Implementing Decision], and in
particular to Article 5 thereof,
Has adopted the following rules of procedure:
Article 1
Membership - notification and withdrawal
1. The notification referred to in Article 3(2) of the Implementing Decision shall be addressed
in writing to the Commission, to the attention of the chair.
2. Membership shall take effect one month after the receipt of this notification.
3. Member States shall inform the Chair in writing of the name of their representative.
Continuity of representation shall be aimed. Representatives can be accompanied by national
experts. Within a reasonable time and no later than 5 calendar days before the date of a
Network meeting, the names and functions of the experts and the reasons for which their
presence is required, shall be communicated to the secretariat of the Network.
4. A Member State wishing to withdraw from the Network shall send a written notification
with a three-month notice.
Article 2
Chair
1. The Network shall be co-chaired by the Commission's Director General for Health and
Consumers, or her/his alternate, and by the representative of a Member State participating in
the Network.
2. The Member State representative referred to in paragraph 1, shall be appointed for a period
of two year, amongst the Member States representatives of the Network, according to the
modalities laid out in Article 7.
Commission européenne/Europese Commissie, 1049 Bruxelles/Brussel, BELGIQUE/BELGIË - Tel. +32 22991111
Office B232 08/109, tel direct line: +32 22980394
e- mail address:
[email protected]. eu
3. The Chair shall have neither voting rights nor any casting vote, yet the Member State,
whose representative is holding the chair, shall nominate another representative to the
network and shall retain its voting rights as a Member of the Network.
Article 3
Convening a meeting
1. Meetings of the Network are convened by the Chair, either on his/her own initiative, or at
the request of a simple majority of Members.
2. Meetings of the Network shall be held on Commission premises unless otherwise decided
by the Network members.
Article 4
Secretariat
In accordance with Article 7(1) of the Implementing Decision, the Commission shall provide
secretarial support for the Network and any sub-groups created by the Network.
Article 5
Agenda
1. The Secretariat shall draw up the agenda, after consultation of the chairs, taking into
account the work and the results of the 'High-level mechanism of eHealth governance' Joint
action1 and Thematic network set up respectively under the Health Programme2 and the ICT
Policy Support Programme of the Competitiveness and Innovation Programme3 and other
projects and initiatives with direct relevance to the Network's objectives in accordance with
the multi annual work programme that the eHealth network shall adopt in accordance with
Article 6 of the Commission Implementing Decision.
2. The agenda shall be adopted by the Network at the start of the meeting.
Article 6
Documentation to be sent to Network members
1. The secretariat shall send the invitation to the meeting and the draft agenda to the Network
Members no later than thirty calendar days before the date of the meeting.
1
Commission Decision C(2010)7593 of 27 October 2010 on the awarding of grants for proposals for 2010 under
the second Health Programme, Annex IV, ref. n° 100868.
2
Decision No 1350/2007/EC of the European Parliament and of the Council of 23 October 2007 establishing a
second programme of Community action in the field of health (2008-13).
3
Decision No. 1639/2006/EC of the European Parliament and of the Council of 24 October 2006 establishing
the Competitiveness and Innovation Framework Programme.
2. The secretariat shall send the documents for consultation to the Network Members no later
than fourteen calendar days before the date of the meeting.
3. In duly justified cases, the time limits for sending the documentation mentioned in 1 and 2
may be reduced to five calendar days before the date of the meeting.
Article7
Adoption of deliverables of the Network
1. As far as possible, the Network shall deliberate by consensus. Abstentions shall not prevent
the adoption of deliberations by consensus.
2. A vote shall be taken if any Network Member so requests. In the event of a vote, the
outcome of the vote shall be decided by a majority of two thirds of the Networks'
Members present when the Chair proceeds to the vote. Each Member State shall have
one vote. Absent Member State's vote shall count in the vote if a written mandate is
given to another Network's Member.
Article 8
Sub-groups
1. The sub-groups referred to in Article 6 of the Implementing Decision shall be chaired by
rapporteurs appointed by the Chair. Such sub-groups shall be disbanded as soon as their
mandate is fulfilled.
2. The sub-groups shall report to the Network.
Article 9
Admission of third parties
The Chair may invite on an ad hoc basis experts from outside the Network with specific
competence in a subject on the agenda to participate in the work of the Network or sub-groups.
In addition, the Chair may give observer status to national authorities responsible for eHealth
of EEA/EFTA countries and of accession countries.
Article 10
Written procedure
1. If necessary, the Network's opinions, conclusions, recommendations, or reports on a
specific question may be delivered via a written procedure. To this end, upon request of the
Chair, the secretariat sends the Network Members the document(s) on which the Network is
being consulted and, where appropriate, sets a time limit for observations.
2. The secretariat shall inform the Network of the outcomes of the written procedure.
3. However, if a simple majority of Network Members asks for the question to be examined at
a meeting of the Network, the written procedure shall be terminated without result and the
Secretariat shall convene a meeting of the Network as soon as possible.
Article11
Summary minutes of the meetings
1. Summary minutes on the discussion on each point on the agenda and the opinions delivered
by the Network shall be drafted by the secretariat and send out to the Network members
without delay and no later than 15 working days after the meeting.
2. The Network's members shall send any comments they may have on the draft summary
minutes to the secretariat in writing.
3. The summary minutes shall not mention the individual position of the Members during the
Network's deliberations.
Article 12
Attendance list and Conflicts of interest
1 At each meeting, the secretariat shall draw up an attendance list specifying the authorities
and organisations to which the persons designated by the Member States to represent them
belong.
2. At the beginning of each meeting, any person designated by the Member States, as well as
experts and representatives of third parties who have been invited to attend the meeting, shall
inform the chair of any conflict of interest4 with regard to a particular item on the agenda.
3. In the event of such a conflict of interest, the person concerned shall, at the request of the
chair, withdraw from the meeting whilst the relevant items of the agenda are being dealt with.
4. Conflicts of interest shall be reported in writing, e.g. in the summary minutes of the
Network's meeting.
5. Paragraphs 1, 2, 3 and 4 shall also apply to deliberations taken by the Network in written
procedure.
Article 13
Correspondence
4
As an example, Article 52(2) of Council Regulation (EC, Euratom) No 1605/2002 of 25 June 2002 on
the Financial Regulation applicable to the general budget of the European Communities (OJ L 248, 16.09.2002,
p. 1) contains a specific definition of a conflict of interest.
1. Correspondence relating to the Network shall be addressed to the secretariat, for the
attention of the Chair.
2. Correspondence for Network Members shall be sent to the e-mail address or addresses
which they provide for that purpose.
Article 14
Access to documents
Requests for access to Network's documents shall be handled in accordance with Regulation
(EC) No 1049/20015. It is for the Commission to take a decision on requests for access to
those documents pursuant to its Rules of Procedure as amended by Decision 2001/937/EC,
ECSC, Euratom6. If the request is addressed to a Member State that Member State shall apply
Article 5 of Regulation (EC) No 1049/2001.
Article 15
Confidentiality of deliberations
1. The Network's deliberations shall be confidential.
2. The Network may, by a simple majority of its Members, decide to open its deliberations to
the public.
Article 16
Protection of personal data
All collecting, processing and publishing of personal data for the purposes of these rules of
procedure shall be in accordance with Regulation (EC) No 45/20017 and Directive 95/46/EC8
where applicable.
5
Regulation (EC) No 1049/2001 of the European Parliament and of the Council of 30 May 2001
regarding public access to European Parliament, Council and Commission documents (OJ L 145, 31.5.2001 p.
43).
6
Commission Decision of 5 December 2001 amending its rules of procedure (2001/937/EC/ECSC,
Euratom, OJ L 345, 29.12.2001, p. 94).
7
Regulation (EC) 45/2001 of the European Parliament and of the Council of 18 December 2000 on the
protection of individuals with regard to the processing of personal data by the Community institutions and bodies
and on the free movement of such data (OJ L 8, 12.1 2001, p. 1).
8
Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the
protection of individuals with regard to the processing of personal data and on the free movement of such data
(OJ L 281, 23.11.1995, p. 31).
eHealth Network
GUIDELINE
on
the electronic exchange of health data under Cross-
Border Directive 2011/24/EU
Release 2
General guidelines
eHealth Network
The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth. The Joint
Action supporting the eHealth Network (JAseHN) provides scientific and technical support to the
Network.
Adopted by consensus by the eHealth Network, Brussels, 21 November 2016
2
eHealth Network
-Keep this page free-
3
eHealth Network
TABLE OF CONTENTS
1. GUIDELINES FOR ELECTRONIC EXCHANGE OF HEALTH DATA.................................................. 5
Chapter I – General Considerations ................................................................................................. 6
Chapter II – Legal and Regulatory Considerations ........................................................................ 7
Chapter III – Organisational and Policy Considerations ............................................................... 8
Chapter IV - Semantic Considerations ............................................................................................ 9
Chapter V – Technical Considerations ............................................................................................ 9
Chapter VI – Amendments ............................................................................................................. 10
2. SUPPORTING INFORMATION ....................................................................................................... 11
Chapter I - General Considerations ............................................................................................... 11
Chapter II – Legal and Regulatory Considerations ...................................................................... 11
Chapter III – Organisational and Policy Considerations ............................................................. 12
Chapter IV - Semantic Considerations .......................................................................................... 14
Chapter V – Technical Considerations .......................................................................................... 14
4
eHealth Network
1. GUIDELINES FOR ELECTRONIC EXCHANGE OF HEALTH DATA
THE MEMBER STATES in the eHealth Network,
Having regard to the Treaty on the Functioning of the European Union, and in particular
Articles 114 and 168 thereof,
Having regard to 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, and in
particular Article 14 thereof,
WHEREAS:
(1) According to Article 168 (1) of the Treaty on the Functioning of the European Union
(TFEU), a high level of human health protection is to be ensured in the definition and
implementation of all Union policies and activities.
(2) Based on Articles 114 and 168 of the TFEU, the Union adopted 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.
(3) Article 14 (2) (b) (i) of Directive 2011/24/EU identifies an objective of the eHealth
Network to draw up guidelines on a non-exhaustive list of data that are to be included in
Patient Summaries that can be shared between health professionals to enable continuity of
care and patient safety across borders and guidelines on ePrescriptions.
(4) The Member States adopted Release 1 of the Patient Summary Guidelines in November
2013 and Release 1 of the ePrescription Guidelines in November 2014.
(5) The Member States have been playing an active role in the revision of the guidelines, in
particular by providing their knowledge and experience, and adopted the Organisation
Framework (OFW) in November 2015.
(6) Preliminary work in the field of eHealth, in particular by the European large scale pilot
“European Patients’ Smart Open Services” (epSOS), the CALLIOPE Network and the
eHealth Governance Initiative (eHGI), shall provide a solid and reliable foundation for this
guideline.
(7) As cross-border services take place in the field of public health and in accordance with
Article 14, the goal must be to use open standards wherever possible.
(8) REGULATION (EU) 2016/679 of 27 April 2016 on the protection of natural persons
with regard to the processing of personal data and on the free movement of such data
(General Data Protection Regulation) forms the legal basis for using personal health data.
This supersedes Directive 95/46/EC.
(9) Regulation (EU) N°910/2014 on electronic identification and trust services for electronic
transactions in the internal market (eIDAS Regulation) provides a predictable regulatory
environment to enable secure and seamless electronic interactions between businesses,
citizens and public authorities.
HAVE ADOPTED THESE GUIDELINES:
5
eHealth Network
Chapter I – General Considerations
Article 1: Objectives and scope
1. These guidelines, as adopted by the eHealth Network, are addressed to the Member
States of the European Union and apply to the implementation of cross-border data
exchange.
2. These guidelines aim to support the Member States to achieve a minimum level of
interoperability, taking considerations of patient safety and data protection into account, by
defining requirements for communication between their respective eHealth National Contact
Points (as defined in Article 2) and interfaces between national and European levels.
3. According to the primary responsibility of the Member States in the field of healthcare
provision, as laid down in Article 168 (7) of the Treaty on the Functioning of the European
Union, these guidelines are non-binding. In a cross-border context, interoperability is
essential to the provision of high quality care. Member States shall therefore engage in taking
appropriate measures to make their respective information systems interoperable, both
technically and semantically, for those Use Cases agreed by the eHN. This serves the
purposes of the internal market according to Article 114 of the Treaty on the Functioning of
the European Union.
Article 2: Definitions
1. For the purpose of this guideline, the definitions of the directives cited within the recitals
of this guideline and the following definitions shall apply:
a) ‘Health care professional’ means a doctor of medicine, a nurse responsible for general
care, a dental practitioner, a midwife or a pharmacist within the meaning of Directive
2005/36/EC1, or another professional exercising activities in the healthcare sector, which are
restricted to a regulated profession as defined in Article 3 (1) (a) of Directive 2005/36/EC,
or a person considered to be a health professional according to the legislation of the Member
State of treatment.
b) ‘Interoperability’, within the context of European public service delivery, is the ability of
disparate and diverse organisations to interact towards mutually beneficial and agreed
common goals, involving the sharing of information and knowledge between the
organisations, through the business processes they support, by means of the exchange of
data between their respective ICT systems. (European Interoperability Framework)
c) ‘eHealth National Contact Point’ refers to the unique entity on a national level authorised
by a Member State to provide an interface between the national and European aspects of
cross-border exchange2.
Article 3: Concept and intended use
1. Each Annex to these guidelines describes Use Cases relating to the intended scope and
purpose for cross-border exchange.
2. These guidelines are non-binding in relation to Member States’ national implementation,
notwithstanding Member States are considered to:
(b) use open standards for public health activities;
(c) decide freely whether they want to adopt such requirements into local legislation;
(d) bear in mind these guidelines when adapting their legislation.
1
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2005:255:0022:0142:en:PDF
2
Each Member State may establish one or more of these entities (at regional/local level) depending on the
respective National Health Service model.
6
eHealth Network
Chapter II – Legal and Regulatory Considerations
Article 4: Data protection
1. The implementation of these guidelines is in line with Directive 95/46/EC on the
protection of personal data and free movement of such data, and will be updated to reflect
the requirements of the General Data Protection Regulation.
2. In the meantime, national legal frameworks define the conditions under which health
data may be shared, making provisions for specific safeguards that need to be in place
without, however, being prescriptive of such safeguards. Member States should ensure they
have measures in place to assure and evaluate their own compliance.
3. Data contained in health records are “sensitive personal data” and therefore Member
States will need to ensure processing and storage are in line with legal and data protection
requirements. In particular, Member States may need to implement consent management for
the processing and storing of data and subsequent authorised access.
Article 5: Authorisation, authentication and identification
1. Member States shall adopt the Organisational Framework for their eHNCP that
comprises the commonly adopted policies, processes and audit mechanisms for cross-border
care.
2. Member States shall ensure validation of foreign patients’ identity.
3. Member States shall ensure their eHNCP enforces identity authentication of health
professionals who use cross-border services.
4. Member States may wish to consider the content of a register of health professionals
who are entitled to prescribe and dispense, for instance:
(a) the name and profession,
(b) a personal identification number, including the ISO 3166 country code,
(c) the current address of the health care provider organisation with which the health
professional is affiliated or the address of his or her private practice,
(d) the date of issue of the healthcare professional’s licence to practice,
(e) the speciality may be recorded in line with national practice as the prescribing of some
medicinal products may be restricted.
Article 6: Patient safety
1. Health professionals, patients and National Contact Points for eHealth can rely upon the
information released by the eHNCP of other Member States.
2. In the event of semantic transformation, both the transformed and the original documents
shall for safety and audit reasons be available to all persons who are authorised to use this
data.
3. Liability for errors in the semantic transformation will be as described in the Legal
Agreement.
7
eHealth Network
Chapter III – Organisational and Policy Considerations
Article 7: Enablers for implementation
1. The application of these guidelines should at all times take place according to the
provisions of relevant European and national legislation. Where such provisions do not exist
or are not in force, Member States are expected to implement, monitor and audit common
policies, safeguards and measures representing agreements of the eHealth Network.
2. Such agreements will apply to the exchange of health related data across borders in a
generic way and they will include but are not limited to agreements on duties and
responsibilities of the eHNCPs and on common identification, authentication and
authorisation measures.
3. Member States participating in cross-border exchange shall set up an eHNCP compliant
with the OFW. This should be unique to each Member State in its relationship with other
Member States, i.e. a single eHNCP communication gateway should be responsible for
interaction with the eHNCP for each other Member State for cross-border services.
4. Member States must ensure that their eHNCP establishes the connection with the
national infrastructure, ensuring that appropriate processes and procedures are in place
(security measures, safeguards etc.).
5. The entry into operation of an eHNCP requires the explicit approval of the coordination
mechanism established through the eHealth Network for the cross-border environment.
6. Non-EU countries may operate in line with Cross-Border Directive 2011/24/EU with
the explicit approval of the eHealth Network.
7. Participating Member States should establish adequate monitoring procedures for their
eHNCP.
Article 8: Quality standards and validation
1. Each Member State should apply such quality and safety standards as eHN might agree
in the process of coding the information, such as validation checking.
2. In order to assure safe implementation, particularly patient safety and data protection,
and further development of cross-border eHealth services, Member States should:
a) consider setting up a facility for cross-border services to quality assure, benchmark and
assess progress on legal, organisational, technical and semantic interoperability for their
successful implementation;
b) undertake assessment activities, such as measuring the quantitative and qualitative
possible benefits and risks (including economic benefits, risks and cost-effectiveness) of
cross-border services.
Article 9: Education, training and awareness
1. In terms of education, training and awareness raising, Member States should:
a) undertake activities towards increasing awareness of the benefits of and need for
interoperability and related standards and specifications for electronic cross-border patient
data exchange, including awareness of the need to foster the interoperability of technical
systems among producers and vendors of information and communication technologies,
healthcare professionals, health care providers, public health institutions, insurers and other
stakeholders
8
eHealth Network
b) pay particular attention to education, training and dissemination of good practices in
electronically recording, storing and processing patient information
c) initiate appropriate, easy to understand information and awareness raising measures for
all individuals, in particular patients
d) consider recommendations for education and awareness raising measures targeting health
policymakers and health professionals.
Chapter IV - Semantic Considerations
Article 10: Data
1. Safe and secure cross-border care requires an ability to convey both meaning and context
in data exchange. It is agreed that to achieve this, it is necessary to have structured and coded
data for identified fields.
2. The responsibility for the accuracy and integrity of the process is with each national
designated competent entity for such semantic processing.
Article 11: Terminology
1. The eHNCP must use the latest version of the Master Valueset Catalogue and
the maintained national versions of these controlled vocabularies used in semantic
transformation.
2. Member States must ensure the eHNCP performs semantic transformation (e.g.
translation and mapping), which is needed for the cross-border information exchange.
3. Member States wishing to engage in cross-border communication must provide
conformant messages operating to standards agreed by the eHN. Internally, Member
States may perform mapping, transcoding and translation activities to local codes to
support such activity.
4. Further work is needed to review the code schemes used for cross-border
scenarios. Member States will work with the agreed governance arrangements of the
eHealth Member State Expert Group (eHMSEG) to achieve this.
Article 12: Master Catalogue
Agreement on a set of coding schemes as set out in Article 11 will require a master catalogue
at EU level which can be used by all Member States to share value sets, allowing each
Member State to translate and transcode schemes, if required, to their national equivalents. It
is expected that the eHN will agree on the mechanism by which the Master Catalogue will be
maintained and published.
Chapter V – Technical Considerations
Article 13: Technical requirements
1. Member States must provide a gateway service, a request port and a semantic
transformation service in order to enable the core steps for relevant cross-border use cases to
be executed.
2. The eHNCP shall guarantee that all cross-border service requirements and specifications
(legal, organisational, semantic and technical) agreed by the eHN are fulfilled.
3. The eHNCP must ensure the appropriate interface with the core services set up at EU
level.
9
eHealth Network
Article 14: Security
1. The eHNCP Security Policy Baseline creates a general security and data protection
baseline adapted to cross-border needs. This was approved by the eHealth Network as
Annex A to the Organisational Framework.
2. Member States shall ensure that they are fully compliant with the cross-border security
policy.
3. The eHNCP shall take all reasonable steps to ensure data security (including data
confidentiality, integrity, authenticity, availability and non-repudiation).
4. The eHNCP must ensure that cross-border data is not transmitted via these services to a
Member State that either does not belong to or is not allowed into the cross-border
environment.
5. Member States shall ensure that communication of identifiable personal health data is
subject to secure communication and end-to-end security measures.
6. Member States shall ensure that their eHNCPs establish an appropriate system of audit
trail and shall
a) allow authorised official bodies to duly inspect the established mechanisms for data
collection, processing, translation and transmitting
b) make logs available for legal purposes, e.g. if requested by a patient.
7. The Member States must ensure that the eHNCP has clearly identified the responsible
data controller and data processor in accordance with the provisions of General Data
Protection Regulation.
Article 15: Testing and audit
1. Member States will need to establish testing mechanisms that demonstrate compliance
with standards agreed by the eHN. For cross-border purposes, a Europe-wide testing
process will also be required, including validation of data fields against defined criteria (e.g.
dates in valid date format).
2. Testing will be supported by processes and tools agreed by the eHN. Member States
shall ensure that their eHNCP meets the interoperability specifications and security
requirements.
3. The eHNCP shall establish and maintain an incident management solution to support
health professionals, healthcare providers and citizens in its territory.
4. The eHNCP must ensure an auditing mechanism for legal, organisational, semantic and
technical requirements.
Chapter VI – Amendments
Article 16: Amendments to the guidelines
The eHealth Network is responsible for updating the guidelines.
These guidelines are addressed to Member States.
10
eHealth Network
2. SUPPORTING INFORMATION
This chapter provides supporting information and explanatory text to aid understanding of
the guidelines, and the rationale behind the proposals. It therefore follows the same structure
as the guidelines themselves.
Chapter I - General Considerations
Article 1: Objectives and scope
The primary objective of these guidelines is to support implementation of eHealth Digital
Service Infrastructure Use Cases under CEF.
Article 2: Definitions
The definitions section focuses on concepts which are common to cross-border health.
Article 3: Concept and intended use
The contents of these guidelines are seen as required for cross-border exchange, but also as
advice that will help each Member State to make progress in terms of its own agenda.
Chapter II – Legal and Regulatory Considerations
Article 4: Data protection
The General Data Protection Regulation and its subsequent Delegated and Implementation
Act aim to improve consistency and reduce diversity in data protection and rights including
access to personal data and deletion or suppressions of sensitive information. As such, it
could in the future abolish the need for specific data protection agreements and, together
with the transposition of Directive 2011/24/EU, significantly reduce the scope of such
(interoperability) agreements.
A common cross-border website should provide information about the specific rights of
data subjects according to the different legislations of all the participating Member States.
The information on the website should clearly specify the rights, conditions and practicalities
according to the national legislation of each Member State.
Article 5: Authorisation, authentication and identification
Issues of identification, authentication and authorisation of patients and health professionals
involved in cross-border care relationships are crucial elements. To be able to link patients
with their patient records, the existence of a patient identifier is necessary.
Besides having means to identify a patient, facilities to identify a health professional or health
care provider organisation are a prerequisite for maintaining a high level of confidentiality for
medical information when it is exchanged in a secure manner between other health
professionals/health care provider organisations. The health professional/health care
provider organisation identifier is linked to a digital identity which is issued by a certified
authority. This identifier provides a base to create a trust circle between health
professionals/health care provider organisations and is also a precondition for electronic
signing by the health professional/health care provider organisation.
11
eHealth Network
Member States will have to consider their approach to implementing digital signature
services at the eGovernment or eHealth service level in the light of the electronic
identification and trust services (eIDAS3) regulation adopted in July 2014.
For functions such as ePrescribing, the identification of the health professional will need to
be linked to access the data (i.e. confirmation of patient consent) and the authorisations to
prescribe. Datasets to enable this are available from some Member State competent
authorities, but further work is required for professional bodies to support cross-border
ePrescribing.
The digital ID of the health professional and/or health care provider organisation is also
used for authentication purposes by a majority of Member States. Similarly, the majority
make use of digital signing for health professional/health care provider organisations in their
country. In some countries a prescription is not valid without the (electronic) signature of the
health professional.
For most Member States, the digital identity of the health professional is linked to the health
professional role, and authorisation for accessing patient information is based on the role,
e.g. GP or pharmacist, of the health professional. In most of these Member States, this is
based on the digital identity of the health professional. In the majority of Member States, the
health professional prescribing role or health professional medication dispensing role can be
inferred from the digital identity of the health professional.
Article 6: Patient safety issues
The semantic transformation is performed according to the translation, mapping and
transcoding performed by designated competent legal entities in the cross-border countries,
in which:
the responsibility for the accuracy and integrity of the process is with each national
designated competent legal entity for such semantic processing
liability for errors in the semantic mapping is a shared cross-border responsibility
between the respective Member States.
Chapter III – Organisational and Policy Considerations
Article 7: Enablers for implementation
Each Member State would be expected to have one “eHealth National Contact Point”
(eHNCP), which is the technical and organisational entity that ensures interoperability across
national borders with other Member States and decouples the national infrastructure from
other Member States.
The first consequence is that the external interface (with the other eHNCP) is standardised,
with specifications of protocols, procedures and exchanged documents. The interface with
the national infrastructure is specified at a conceptual level, but each Member State remains
free to adopt the most suitable solution to interface the eHNCP with their national
infrastructure.
The organisational setup and procedures for operating the eHNCP are based on ITIL
(Information Technology Infrastructure Library). The selected service and support processes
have been deemed a minimum requirement for operating the eHNCPs in a coherent way.
3
http://ec.europa.eu/digital-agenda/en/trust-services-and-eid
12
eHealth Network
“Regional replicas” of both the technological and organisational arrangements of a typical
eHNCP, which constitute a Regional Contact Point (RCPeH), are possible and follow the
same principles and requirements. If an MS has two or more Regional Contact Points, it
needs to nominate one to act as an eHNCP, to act as the national gateway vis-à-vis the
eHNCP of another MS. Participating MS should make adequate arrangements to ensure
eHNCP readiness for operation of cross-border services and level of service sustainability
(by following the compliance establishment process described in Article 15).
Each Member State must have its own national support organisation in place and publish
information about the responsible persons. There should be a central service desk for
managing incidents, problems and changes and the interface between the national and central
service desks should be arranged.
All Member States must have incident management in place, including a service desk
function. This service desk function may differ from country to country but is likely to act as
the co-ordinating centre for any users having difficulty accessing patient summaries or
ePrescriptions. Incident management is important for the individual Member State as well as
for the cross-border electronic exchange aspect; Member States should be able to contact
each other in the event of technical or organisational problems.
Problem management aims to resolve the root causes of incidents and thus to minimise
the adverse impact of incidents and problems on business that are caused by errors within
the IT infrastructure, and to prevent recurrence of incidents related to these errors. Member
States must have organised ways to solve problems.
Change management aims to ensure that standardised methods and procedures are used
for efficient handling of all changes in the technical setup, in the organisational setup or in
practical matters in a Member State. Each Member State must have a documented process
for implementing changes of technical, organisational and practical kinds. The change
process must include proper planning and ensure that sufficient information has been
disseminated to other Member States.
Article 8: Quality standards and validation
The semantic transformation is performed according to the translation, mapping and
transcoding carried out by designated competent legal entities in each Member State. The
responsibility for the accuracy and integrity of the process is with each national designated
competent legal entity for such semantic processing.
Article 9: Education, training and awareness
Member States should take steps to engage in education, training and awareness raising.
Such an approach would promote the more effective use of health information as patients
move between a variety of health care providers, along the continuum of care, and receive
treatment and care wherever they are in Europe. Suggested activities might include:
national training materials and activities to be provided to support CBeHIS operation
participating MS engage health professionals/health care providers in specification
updates and other clinical concerns related to the operation of services
participating MS inform citizens about CBeHIS provisions, including a description of the
national infrastructure.
13
eHealth Network
Chapter IV - Semantic Considerations
Article 10: Data
The epSOS pilot operated on the twin principles of building on what is available and not
interfering with the internal systems in a Member State. The need to maintain consistency
with existing developments added more constraints to the initial clinical definitions.
Article 11: Terminology
These guidelines focus on the content issues and the description of possible ways to produce
this content for cross-border exchange, taking into consideration existing national
implementations.
To ensure the highest quality of data and to avoid loss of information, documentation at the
point of care should use these international standardised terminologies on which the Master
Valueset Catalogue is based. In order to achieve a high quality of data and to avoid loss of
information, it is recommended to integrate documentation into the MVC internationally
agreed standardised terminologies at the HCP. This would enable a 1:1 transfer without loss
of information.
The European Commission initiated three projects under Horizon 2020 to look at aspects of
this: eStandards, OpenMedicine and AssessCT. The respective outcomes will inform future
developments. The Commission is also engaged in discussions with relevant SDOs regarding
licensing arrangements.
Article 12: Master Catalogue
Across Europe, there are different languages, different standards and different coding
schemes. In epSOS, this was addressed by the use of two master files: the Master Value Sets
Catalogue (MVC), which applies across all Member States, and the Master
Translation/Transcoding Catalogue (MTC).
The MVC are supported by an EU-wide Central Reference Terminology Server which will be
maintained by DG SANTE. Each Member State needs its own local terminology repository
as the MTC. If an update is made to the central reference terminology server, the local
terminology repositories are notified and updated.
Chapter V – Technical Considerations
Article 13: Technical requirements
Internally Member States might base their national implementations on international
standards such as EN13606. For the exchange of data across borders, a shared document
structure is needed.
Article 14: Security
Security includes general security of the connected networks and infrastructures. Please
consider referencing appropriate parts of Directive (EU) 2016/1148 concerning measures
for a high common level of security of network and information systems across the Union
(NIS directive).
The diversity of national and regional healthcare systems, their structures, cultures and roles
of health professionals are taken into account by a “common trust model”, which provides
the basis for interoperability via eHNCPs. These entities are designated by the Member
14
eHealth Network
States and serve on the one hand as interfaces between the national and European
requirements for exchanging personal health data, and on the other as guarantors regarding
the origin and content of personal health data.
For security purposes logging of transactions, e.g. a health professional request for a Patient
Summary, is an important feature. Unauthorised access to private medical data can be
detected or prevented when a transactions log is available. Logged information in most cases
consists of who has accessed information, when information was accessed, and what
information was requested.
In most Member States, a tool is used to identify suspicious behaviour or other anomalies
based on available logging data. Misuse of private medical data could be detected or even
prevented using this functionality.
Article 15: Testing and audit
Member States will need to implement software to support cross-border exchange. One
option would be to re-use the Open Source components developed in epSOS (“Open
NCP”) and released for all in the “JoinUp” EC-supported Open Source Community. These
components can be adopted by participating nations and system integrators to build their
own eHNCP solution.
The eHealth Network takes the decision about whether to admit an eHNCP to join the
cross-border services on the basis of the audit report issued following the audit process as
described in the OFW.
In order to ensure monitoring and evaluation of cross-border services and related
interoperability provisions and systems, Member States should:
consider setting up a monitoring facility for cross-border services to monitor,
benchmark and assess progress on technical and semantic interoperability for their
successful implementation;
undertake assessment activities, such as measuring the quantitative and qualitative
possible benefits and risks (including economic benefits and cost-effectiveness) of
services.
Article 16: Amendments to the guidelines
The eHealth Network will be responsible for agreeing amendments to these guidelines. It is
expected that updates will be conducted following consultations with a wide range of
stakeholders.
15
eHealth Network
GUIDELINE
on
the electronic exchange of health data under Cross-
Border Directive 2011/24/EU
Release 2
Patient Summary for unscheduled care
eHealth Network
The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth. The
Joint Action supporting the eHealth Network (JAseHN) provides scientific and technical
support to the Network.
Adopted by consensus by the eHealth Network, Brussels, 21 November 2016
2
eHealth Network
-Keep this page free-
3
eHealth Network
TABLE OF CONTENTS
1. USE CASE DESCRIPTION ...................................................................................................... 5
1.1. Cross-border Patient Summary for Unscheduled Care .................................................... 5
2. GUIDELINES FOR PATIENT DATASET .................................................................................. 7
Chapter I – General Considerations ....................................................................................... 7
Chapter II – Legal and Regulatory Considerations ................................................................ 7
Chapter III – Organisational and Policy Considerations ........................................................ 8
Chapter IV – Semantic Considerations .................................................................................. 8
Chapter V – Technical Considerations ................................................................................... 9
3. SUPPORTING INFORMATION ............................................................................................. 10
Chapter I - General Considerations ..................................................................................... 10
Chapter II – Legal and Regulatory Considerations .............................................................. 10
Chapter III – Organisational and Policy Considerations ...................................................... 11
Chapter IV – Semantic Considerations ................................................................................ 11
Chapter V – Technical Considerations ................................................................................. 12
4. PATIENT SUMMARY DATASET ......................................................................................... 13
5. STANDARDS AND PROTOCOLS .......................................................................................... 17
4
eHealth Network
1. USE CASE DESCRIPTION
1.1. Cross-border Patient Summary for Unscheduled Care
This Use Case represents a high level of consensus on what constitutes European eHealth
services, as this Use Case was described by Directive 2011/24/EU of 9 March 2011 on the
application of patients’ rights in cross-border healthcare.
Use Case description:
Title Patient Summary sharing on a cross-border scale
Purpose Sharing information about the medical background and history of a patient from
Country A (the patient’s country of affiliation) with a healthcare professional in
another Member State Country B (the country of treatment)
Relevance Many people request medical help when travelling, working or living abroad.
Medical information from the country of origin should be available to all citizens in
Europe (in their native language). The current solutions (if any) for obtaining
medical information from another country are often cumbersome, unsafe,
incomplete and non-standard. The treatment of patients without proper medical
background information is hazardous and should be avoided. Benefits can be
gained from increased quality of care (e.g. patient safety) (both medical and
economical) and from a decrease in the effort of gathering/exchanging health
information. This Use Case proposes a way towards solving this problem.
Domain Patient Summary
Situation Cross-border
Context The definition of a Patient Summary was laid down by the epSOS project as a
starting point for the development and pilot testing of a Patient Summary for
citizens who are travelling abroad and need medical help (unplanned).
Challenges are related to the level of data required and the quality of information
relevant to support patient treatment effectively across different participating
European countries. Different countries operate different health care systems,
support their own culture for healthcare provision, and may use a different (or
several different) language(s).
A Patient Summary provides background information on important aspects such as
allergies, current medication, previous illnesses and surgeries, etc. These are
necessary for the proper treatment of a patient abroad, especially when there is a
language barrier between the healthcare professional (HP) and the patient.
Two Use Cases are possible with regard to the Patient Summary (PS). The first is
the one in which an occasional visitor needs his/her PS in country B. The second is
the one in which the person is a regular visitor in country B (i.e. someone who lives
in one country but works in another country). The distinguishing characteristic is
that the HP may have some information available from previous encounters in this
type of occasional situation. Both a PS from country A and one from country B
need to be consulted. In this Use Case, the Use Case of the occasional visitor is
described.
Information Patient Summary (in patient’s language and country B language)
Patient consent
Participants Patient
5
eHealth Network
Health professional in patient’s country of origin/affiliation (country A)
Health professional in country of treatment (country B)
Functional process (With the reservation that preconditions are met)
steps The patient consults a health professional in country B
The patient is identified (identity confirmed by country A)
The health professional is identified, authenticated and authorised
The patient may have given consent before travelling to country B or in country B
to the health professional (except for emergency cases)
In the latter case, the health professional will then register this confirmation
The Patient Summary is electronically transferred from the patient’s country of
origin to the health professional in the country that s/he is visiting (the “visiting
country”) in a secure way. The health professional retrieves the Patient Summary
and uses it for the consultation.
The PS is received in both the language of the patient (PDF of original PS) and as a
translated version for the health professional.
Table 1: Patient Summary Use Case description
6
eHealth Network
2. GUIDELINES FOR PATIENT DATASET
THE MEMBER STATES in the eHealth Network HAVE ADOPTED THESE
supplementary clauses to the general guidelines for the electronic exchange of health data
under Cross-Border Directive 2011/24/EU to support the exchange of Patient Summary
data for unscheduled care.
Chapter I – General Considerations
Article 1: Objectives and scope
1. These guidelines, as adopted by the eHealth Network, are addressed to the Member States of
the European Union and apply to the implementation of a patient dataset for cross-border
exchange.
2. According to the primary responsibility of the Member States in the field of healthcare
provision, as laid down in Article 168 (7) of the Treaty on the Functioning of the European
Union, these guidelines are non-binding. In a cross-border context, interoperability is
essential to the provision of high quality care. Member States shall therefore engage in taking
appropriate measures to make their respective information systems interoperable, both
technically and semantically, for this Use Case.
Article 2: Definitions
1. For the purpose of this guideline, the definitions of the directives cited within the recitals of
this guideline and the following definitions shall apply:
a) A Patient Summary is an identifiable “dataset of essential and understandable health information”
that is made available “at the point of care to deliver safe patient care during unscheduled care [and
planned care] with its maximal impact in the unscheduled care”; it can also be defined at a high level
as: “the minimum set of information needed to assure Health Care Coordination and the continuity of care”.
Article 3: Concept and intended use
1. The provisions in the general guidelines apply.
2. The aim of the Use Case is to help support safe, high-quality cross-border care for
emergency or unplanned care events. This does not preclude the Patient Summary being
used for other purposes.
3. The Patient Summary may, by agreement, be used to share information such as that on
rare diseases.
Chapter II – Legal and Regulatory Considerations
Article 4: Data protection
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 5: Authorisation, authentication and identification
1. Implementation of the patient dataset implies that each Member State has addressed enabling
activities such as:
a) Providing an official ID health number for each citizen (with a national federation of IDs if
numerous regional systems are available). For cross-border purposes, a unique patient
7
eHealth Network
identifier is a necessary requirement for each individual patient to be linked to the patient
record in the country of affiliation
b) Maintaining electronic registers of health professionals
c) Agreed levels of authentication of citizens and health professionals
Article 6: Patient safety
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Chapter III – Organisational and Policy Considerations
Article 7: Enablers for implementation
The ability to populate this dataset implies the existence of a local electronic Patient
Summary. Some Member States have implemented, or are in the course of implementing,
national or regional Patient Summaries. Some Member States already have more detailed
summaries from which this summary data can be extracted. Other Member States may use
this guideline for reference for national implementation.
Article 8: Quality standards and validation
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 9: Education, training and awareness
1. Effective sharing of Patient Summary data is dependent on the recording health professional
and the health professional retrieving the Patient Summary being able to share the
understanding of the patient’s condition. MS should therefore take care to ensure appropriate
awareness and training for all.
2. For instance, the presence of a rare disease code might indicate that specific action should be
taken; health professionals need to be aware of this.
Chapter IV – Semantic Considerations
Article 10: Data
1. The content of the Patient Summary dataset is shown in section 4. The Patient Summary data
comprises Patient Administrative Data and Patient Clinical Data.
2. It is the responsibility of the MS to provide data in compliance with these guidelines. Certain
fields may be empty because there is no data for a given patient.
Article 11: Terminology
1. Emergency or unplanned care situations require an ability to convey both meaning and
context in the Patient Summary to enable safe, high-quality care.
2. Member States wishing to engage in cross-border communication will need to use the
coding schemes as described in the dataset in section 4.
Article 12: Master Catalogue
8
eHealth Network
1. There is a particular issue regarding the identification of medicinal products. It is expected
that the coding schemes currently included within the dataset will be replaced by identifiers
developed using the IDMP set of standards. The European Medicines Agency is leading work
on this; further details will be provided in due course.
Chapter V – Technical Considerations
Article 13: Technical requirements
Member States are free to choose the technical implementation of their Patient Summary
dataset. Nonetheless, for cross-border exchange the format of the document for exchange
should be based on standards and profiles as agreed by the eHN. The cross-border
specification is described in section 5, which also refers to supporting requirements and
other relevant documentation.
Article 14: Security
Member States shall assure logging of cross-border transactions and make logs available for
legal purposes, e.g. a health professional request for a Patient Summary is important.
Article 15: Testing and audit
Member States wishing to engage in cross-border communication will need to demonstrate
their compliance to the specification in section 5.
Article 16: Amendments to the guidelines
The eHealth Network is responsible for updating the guidelines, which are addressed to
Member States.
9
eHealth Network
3. SUPPORTING INFORMATION
This chapter provides supporting information and explanatory text to aid understanding of
the guidelines, and the rationale behind the proposals. It therefore follows the same structure
as the general guidelines.
The material in this supporting document has built on earlier epSOS experiences, but cites
follow-on work in EXPAND, in the relevant Horizon 2020 projects and the joint EU/US
Trillium Bridge project.
Chapter I - General Considerations
Article 1: Objectives and scope
The focus on emergency or unplanned care is deliberate in that it requires agreement on
those data items needed when a patient previously unknown to the health professional (HP)
needs treatment. For planned care, additional referral information will typically be provided,
and hence is not within the scope of this release [Release 2] of the guideline.
More recently, the dataset has been reviewed by US stakeholders as part of the Trillium
Bridge project, in line with the EU-US roadmap and MoU collaboration agreement.
Article 2: Definitions
The definitions section has been extended to include a number of relevant definitions relating
to Patient Summaries.
Article 3: Concept and intended use
These guidelines are non-binding and Member States are considered to have the right to
choose freely their way of implementing Patient Summary data systems.
The Patient Summary guidelines focus on the content issues and the description of possible
ways to produce this content for cross-border exchange, taking existing national
implementations into consideration.
The dataset may be used to hold additional information, such as information about rare
diseases, using current data fields.
Chapter II – Legal and Regulatory Considerations
Article 4: Data protection
Each query about the personal data available through cross-border exchange should be for a
real need of access to specific information related to the care or treatment to be provided.
Article 5: Authorisation, authentication and identification
To be able to link patients with their patient records, the existence of a patient identifier is
necessary. For cross-border purposes, a unique patient identifier is also a necessary
requirement for each individual patient to be linked to the patient record in the country of
origin. Analysis of data shows that most Member States already have a national patient
identification number available. In some cases, Member States have a regional patient
identification number.
Official documents, such as a passport, ID card or driver’s licence, seem to be accepted
across MS for authentication. In cases where a patient does not have (access to) a national
10
eHealth Network
patient ID or an identification document, different kinds of personal information elements,
such as the patient’s last name and date of birth, are used to create a unique (temporary) form
of identification.
Article 6: Patient safety
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Chapter III – Organisational and Policy Considerations
Article 7: Enablers for implementation
The aim of the dataset is to support cross-border care. However, the ability to populate this
dataset requires national activity. More advanced and elaborate Patient Summaries exist in
some Member States (MS), but the eHealth Network has agreed that the guideline could
serve as a common baseline for Patient Summaries at national level.
Article 8: Quality standards and validation
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 9: Education, training and awareness
The use of the Patient Summary to record rare disease information has to be a clinical
decision, with leadership and direction from health professional organisations.
Chapter IV – Semantic Considerations
Article 10: Data
Many countries build their Patient Summary information from multiple sources, which
complicates the update of cross-border Patient Summary information. The content of the
dataset is version controlled, subject to change control through the eHMSEG. A number of
proposals have been made for amendments or additions to the dataset (e.g. a proposal from
ValueHealth to expand the “Vital signs” section); these would need to be assessed for impact
through the Change Control process for inclusion.
Article 11: Terminology
Successful sharing of information requires the effective use of standards to support accurate
and complete clinical documentation that is faithful to the patient's situation, and for
electronic health record (EHR) data to be transferred and structurally mapped into a
receiving repository in a way that enables its clinical content to be interpreted with a meaning
that is commonly understood – by computers as well as by persons.
Since code systems such as SNOMED-CT and ICD-10 (to name but two) contain a large
number of terms, it is not practical to use them in their entirety within the European context,
where some Member States might use different code systems which they will have to cross-
reference and/or translate. Certain criteria were used to choose between the most significant
terms and arrive at a reasonable manageable content. It is expected that the eHN will oversee
the process by which code systems are kept under review and ensure that appropriate
licensing arrangements are in place.
11
eHealth Network
Article 12: Master Catalogue
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Chapter V – Technical Considerations
Article 13: Technical requirements
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 14: Security
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 15: Testing and audit
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
12
eHealth Network
4. PATIENT SUMMARY DATASET
PATIENT ADMINISTRATIVE DATA
Variable
Variables Variables
(nesting DEFINITION AND COMMENTS
(nesting level 2) (nesting level 3)
level 1)
National
Identification National healthcare Country ID, unique to the patient in that country.
healthcare patient
1 patient ID Example: ID for United Kingdom patient
ID
The patient’s first name (example: John). This field
Given name
can contain more than one element.
This field can contain more than one element.
Full name Example: Español Smith
Personal Family
Note: some countries require the surname to be the
information name/surname
birth name [to avoid potential problems with
married women’s surnames).
This field may contain only the year if the day and
Date of birth Date of birth
month are not available, e.g.: 01/01/2009
Gender Gender code This field must contain a recognised valid value
Street Example: Oxford Street
House number Example: 221
Address2 City Example: London
Post code Example: W1W 8LG
State or province Example: London
Country Example: UK
Telephone no. Telephone no. Example: +45 20 7025 6161
Email Email Example:
[email protected]
Name of the HP that has been treating the patient.
[the structure of the name will be the same as
Name of the HP
described in ‘Full name’ (given name, family
Preferred HP to name/surname)]
contact3
Telephone no. Example: +45 20 7025 6161
Contact
information Email Email of the HP/legal organisation
Role of that person Legal guardian or contact person
The first name of the contact person/guardian
Given name (example: Peter). This field can contain more than
one element.
Contact person/
legal guardian Family This field can contain more than one element.
name/surname Example: Español Smith
Telephone no. Example: +45 20 7025 6161
Email Email of the contact person/legal guardian
Insurance
Insurance number Insurance number Example: QQ 12 34 56 A
information
Table 2: Patient Summary dataset for patient administrative data
1 Dataset that enables the univocal identification of the patient
2 May vary by country
3 A health professional in country A may need a contact (health professional/healthcare provider) who knows the
patient.
13
eHealth Network
PATIENT CLINICAL DATA
Variable Variables Variables DEFINITION AND COMMENTS
(nesting (nesting level 2) (nesting level 3)
level 1)
Alerts Allergy Allergy description Description of the clinical manifestation of the allergic
reaction. Example: anaphylactic shock, angioedema (the
clinical manifestation also gives information about the
severity of the observed reaction)
Allergy description Normalised identifier
ID code
Onset date Date of the observation of the reaction
Agent Describes the agent (drug, food, chemical agent, etc.) that is
responsible for the adverse reaction
Agent ID code Normalised identifier
Medical alert Healthcare alert Medical alert information: any other clinical information
information (other description that is imperative to know so that the life or health of the
alerts not included patient does not come under threat. Example 1: intolerance
in allergies) to aspirin due to gastrointestinal bleeding. Example 2:
intolerance to captopril because of cough (the patient is not
allergic but can't tolerate it because of persistent cough)
Healthcare alert ID Normalised identifier
code
Medical Vaccinations Vaccinations Contains each disease against which the patient has been
history immunised
Brand name
Vaccinations ID Normalised identifier
code
Vaccination date The date when the immunisation was given
List of resolved, Problem Problems or diagnoses not included in the definition of
closed or inactive description "current problems or diagnosis". Example: hepatic cyst (the
problems patient has been treated with an hepatic cystectomy that
solved the problem and the problem is therefore closed)
Problem ID code Normalised identifier
Onset time Date of problem onset
End date Problem resolution date
Resolution Describes the reason for which the status of the problem
circumstances changed from current to inactive (e.g. surgical procedure,
medical treatment, etc.). This field includes "free text" if the
resolution circumstances are not already included in other
fields such as surgical procedure, medical device, etc., e.g.
hepatic cystectomy (this will be the resolution circumstances
for the problem "hepatic cyst" and will be included in
surgical procedures).
Surgical Procedure Describes the type of procedure
procedures prior description
to the past six
months
Procedure ID Normalised identifier
(code)
Procedure date Date when procedure was performed
14
eHealth Network
PATIENT CLINICAL DATA
Variable Variables (nesting Variables (nesting DEFINITION AND COMMENTS
(nesting level 2) level 3)
level 1)
Medical List of current Problem/diagnosis Problems/diagnoses that fit these conditions: conditions
problems problems/diagnoses description that may have a chronic or relapsing course (e.g. irritable
bowel syndrome, otitis media), conditions for which the
patient receives repeat medications (e.g. diabetes
mellitus, hypertension) and conditions that are persistent
and serious contraindications for classes of medication
(e.g. dyspepsia, migraine and asthma)
Problem ID (code) Normalised identifier
Onset time Date of problem onset
Medical devices and Device and implant Describes the patient's implanted and external medical
implants description devices and equipment upon which their health status
depends. Includes devices such as cardiac pacemakers,
implantable fibrillator, prosthesis, ferromagnetic bone
implants, etc. of which the HP needs to be aware.
Device ID code Normalised identifier
Implant date Date when procedure was performed
Major surgical Procedure Describes the type of procedure
procedures in the description
past six months
Procedure ID Normalised identifier
(code)
Procedure date Date when procedure was performed
Treatment Recommendations Therapeutic recommendations that do not include drugs
recommendations description (diet, physical exercise constraints, etc.)
Recommendation Normalised identifier
ID (code)
Autonomy/invalidity Description Need for the patient to be continuously assessed by third
parties; invalidity status may influence decisions about
how to administer treatments
Invalidity ID code Normalised invalidity identifier (if any, otherwise free
text)
Medication List of current Active ingredient Substance that alone or in combination with one or
summary medicines lists more other ingredients produces the intended activity of
a medicinal product. Example: “paracetamol”
Brand name if a biological medicinal product or when
Exemption: brand justified by the health professional (ref. Commission
name Directive 2012/52/EU)
Active ingredient Code that identifies the active ingredient
ID code
(Relevant prescribed Strength The content of the active ingredient expressed
medicines whose quantifiably per dosage unit, per unit of volume or per
period of time unit of weight, according to the pharmaceutical dose
indicated for the form. Example: 500 mg per tablet
treatment has not
yet expired whether
it has been
dispensed or not)
Pharmaceutical The form in which a pharmaceutical product is
dose form presented in the medicinal product package (e.g. tablet,
syrup)
Number of units The number of units per intake that the patient is taking.
per intake Example: 1 tablet
Frequency of Frequency of intakes per hour/day/week/month.
intakes Example: every 24 hours
Duration of Example: 14 days
treatment
Date of onset of Date when patient needs to start taking the medicine
treatment prescribed
15
eHealth Network
Variable Variables (nesting Variables (nesting DEFINITION AND COMMENTS
(nesting level 2) level 3)
level 1)
Social Social history Social history Health related “lifestyle factors" or "lifestyle
history observations observations observations"
related to Example: cigarette smoker, alcohol consumption
smoking, alcohol
and diet
Reference date Example: from 1974 to 2004
range
Pregnancy Expected date of Expected date of Date on which the woman is due to give birth. Year,
history delivery delivery month and day are required (e.g. 01/01/2014).
Physical Vital signs Blood pressure One blood pressure value which includes: systolic
findings observations blood pressure and diastolic blood pressure
Date when blood Date when blood pressure was measured
pressure was
measured
Diagnostic Blood group Result of blood Result of blood group test performed on the patient
tests group
Date Date on which the blood group was performed. This
field may contain only the year if day and month are
not available (e.g. 01/01/2009).
Table 3: Patient Summary dataset for patient clinical data
METADATA
Variable Variables Variables DEFINITION AND COMMENTS
(nesting (nesting level 2) (nesting level 3)
level 1)
Country Country Country Name of country A
Patient Date created Date created Date on which PS was generated
Summary
Date of last update Date of last update Date on which PS was updated (date of most recent
version)
Nature of Nature of the PS Nature of the PS Defines the context in which it was generated.
the PS Distinguishes between three methodological approaches
for generating the PS: direct human intervention by an
HP, automatically generated approach and mixed
approach
Author Author Author At least one author organisation (HCP) shall be listed. In
organisation organisation organisation the event that there is no HCP, at least one HP shall be
listed
Table 4: Patient Summary dataset for metadata
16
eHealth Network
5. STANDARDS AND PROTOCOLS
Reference is made to three classes of material:
Background requirements and explanatory material
https://ec.europa.eu/cefdigital/wiki/x/30QZAg
Formal technical and semantic specifications
https://ec.europa.eu/cefdigital/wiki/x/30QZAg
Formal terminology bindings
https://ec.europa.eu/cefdigital/wiki/x/30QZAg
17
Ref. Ares(2017)3033026 - 16/06/2017
eHealth Network
GUIDELINE
on
the electronic exchange of health data under Cross-
Border Directive 2011/24/EU
Release 2
ePrescriptions and eDispensations
Joint Action to support the eHealth Network
The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth. The Joint
Action supporting the eHealth Network (JAseHN) provides scientific and technical support to the
Network.
Adopted by consensus by the eHealth Network, Brussels, 21 November 2016
2
Joint Action to support the eHealth Network
-Keep this page free-
3
Joint Action to support the eHealth Network
TABLE OF CONTENTS
1. USE CASE DESCRIPTION ................................................................................................ 5
1.1. Cross-border ePrescription and eDispensing ....................................................... 5
2. GUIDELINES FOR EPRESCRIPTIONS AND EDISPENSATIONS ................. 7
Chapter I – General Considerations .................................................................................... 7
Chapter II – Legal and Regulatory Considerations ....................................................... 8
Chapter III – Organisational Considerations .................................................................. 8
Chapter IV – Semantic Considerations ............................................................................10
Chapter V – Technical Considerations ............................................................................12
3. SUPPORTING INFORMATION....................................................................................13
Chapter I – Scope and Definitions ....................................................................................13
Chapter II – Legal and Regulatory Considerations .....................................................13
Chapter III – Organisational Considerations ................................................................14
Chapter IV – Semantic Considerations ............................................................................15
Chapter V – Technical Considerations ............................................................................16
4. EPRESCRIPTION DATASET .........................................................................................17
A.2 Optional elements of prescription ............................................................................19
5. STANDARDS AND PROFILES.......................................................................................22
6. POTENTIAL REFORMULATION OF MEDICINAL PRODUCT
INFORMATION ...................................................................................................................23
4
Joint Action to support the eHealth Network
1. USE CASE DESCRIPTION
1.1. Cross-border ePrescription and eDispensing
(1) The electronic prescription and dispensing of medications can have different Use Cases
on different organisational scales, and each scale presents a different organisation of the
process. The information below is taken from the Antilope report and relates to cross-border
exchange of data.
(2)
(3) Purpose (4) To support the processes of prescription and dispensation through the
electronic exchange of supporting data for citizens who are travelling inside
Europe, where a patient from Country A (the patient’s country of affiliation) is
seen in another Member State Country B (the country of treatment)
(5) Relevance This Use Case represents a high level of consensus on what constitutes European
eHealth services, as this Use Case was described by Directive 2011/24/EU of 9
March 2011 on the application of patients’ rights in cross-border healthcare.
(6) Benefits in both medical and economic terms can be gained from increased
quality of care (e.g. improved patient safety) when citizens are travelling abroad
and are still able to pick up (lost/forgotten/other necessary reasons) medication
and to decrease the effort of gathering/exchanging health information.
Domain Medication
Situation Cross-border
Context ePrescribing is defined as a prescriber's ability to electronically send an
accurate, error-free and understandable prescription directly to a pharmacy
from the point-of-care (www.cms.gov).
eDispensing is defined as the act of electronically retrieving a prescription and
reporting on giving the medicine to the patient as indicated in the
corresponding ePrescription.
Once the medicine has been dispensed, the dispenser will report, via software,
information about the dispensed medicine(s) to the prescription provider. To
appropriately define the context of the Use Case relevant aspects requires
consideration. These include:
The different legislative contexts in the various European countries have led
to the decision that information about a newly prescribed medicine, in a
country visited by a patient, will not be transferred back to the country in
which the patient resides.
Information Consent – information about patient’s consent
Prescription – information necessary to prescribe the medication
Dispense – information about the dispensed medicine(s)
Participants Prescriber – person responsible for the prescription of medication
Dispenser – person who can hand over the medication to the patient
Patient – person who gives consent and requests medication
Functional (With the reservation that preconditions are met)
process steps The patient visits a health professional and may give his/her consent to share
his/her medical information in country A
The patient may alternatively provide his/her consent electronically in an
electronic record system held in his/her country of origin
The patient then travels abroad where s/he requires medication in another
country (B)
S/he visits a pharmacy in country B
S/he identifies himself/herself to the pharmacist/staff at the pharmacy
5
Joint Action to support the eHealth Network
Pharmacist is identified, authenticated and authorised
The patient asks for his/her ePrescription. By doing so, the patient gives the
dispenser/pharmacist his/her consent to access his/her personal information
The pharmacist requests the patient’s ePrescription via the pharmacy’s
computer in a secure way
The prescription is received by country A via the eHNCP. The eHNCP
checks patient consent, is translated by the semantic services and sent back to
the eHNCP of country B
Pharmacist receives the ePrescription both translated into his/her own
language and as an original copy of the prescription
The requested medication is then dispensed to the patient
The dispensed medicine information is sent back to country A, in real time
and immediately after the medicine has been dispensed.
Table 1: General information about cross-border exchange of data (Antilope report)
6
Joint Action to support the eHealth Network
2. GUIDELINES FOR EPRESCRIPTIONS AND EDISPENSATIONS
THE MEMBER STATES in the eHealth Network HAVE ADOPTED THESE
supplementary clauses to the general guidelines for the electronic exchange of health data
under Cross-Border Directive 2011/24/EU to support exchange of ePrescription and
eDispensation data.
Chapter I – General Considerations
Article 1: Objectives and scope
1. These guidelines are addressed to the Member States of the European Union and apply to
the implementation of interoperable electronic prescription services across Member States, in
order to facilitate the recognition and delivery of prescriptions issued in another Member
State.
2. In particular, while the non-exhaustive list of elements to be included in medical
prescriptions has been fixed in Commission Implementing Directive 2012/52/EU, there is a
need to define the electronic requirements applicable to the seamless identification of the
patient, of the prescribing health professional and of the health product.
3. These guidelines do not cover medical devices; the guidelines do not cover non-
pharmaceutical products.
Article 2: Definitions
1. For the purpose of these guidelines, the definitions of the directives cited within the
recitals of these guidelines and the following definitions shall apply:
a) eDispensing is defined as the act of electronically retrieving a prescription and giving the
medicine to the patient. Once the medicine has been dispensed, a report on the items
dispensed is sent to the prescribing Member State in a structured format.1
b) ‘Electronic medication data’ means any electronically used data regarding medication of a
patient, including but not limited to ePrescriptions and the electronic information about the
dispensation of medication.
c) ‘ePrescription’ means a medicinal prescription issued and transmitted electronically, as
elaborated in point 3 (f) of Commission Recommendation 2008/594/EC on cross-border
interoperability of electronic health records.
d) ‘Medicinal prescription’ means any medicinal prescription, as defined by Article 1 (19) of
Directive 2001/83/EC2, issued by a professional person qualified to do so.
e) ‘Medicinal product’ means
o any substance or combination of substances presented as having properties for treating or
preventing disease in human beings; or
o any substance or combination of substances which may be used in or administered to
human beings either with a view to restoring, correcting or modifying physiological functions
by exerting a pharmacological, immunological or metabolic action, or to making a medical
diagnosis.
1
See supporting detail in Article 6; the aim is that the ePrescription must be updated. This should be done in
real time and immediately after the medicines have been dispensed and certainly before another dispensation
can take place.
2
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2001:311:0067:0128:en:PDF
7
Joint Action to support the eHealth Network
f) ‘Prescription’ means a prescription for a medicinal product or a medical device issued by
a member of a regulated health profession within the meaning of Article 3 (1) (a) of Directive
2005/36/EC, who is legally entitled to do so in the Member State in which the prescription is
issued.
Article 3: Concept and intended use
1. These guidelines operate within the context of the guidelines for cross-border data
exchange.
Chapter II – Legal and Regulatory Considerations
Article 4: Data protection
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 5: Authorisation, authentication and identification
1. Member States shall ensure that, for reasons of authentication, information is available at
national, regional or any other level:
(a) on the health professionals who are entitled to prescribe as well as
(b) on the health professionals/heath care providers who are entitled (according to national
law) to dispense.
2. Member States of affiliation are responsible for ensuring that ePrescriptions are issued
only by registered persons (or, where relevant, organisations).
3. The healthcare professional must be registered with at least one healthcare professional
organisation or health authority belonging to the country in order to identify him or her
unequivocally. Each Member State will need a system to check the attributes (e.g. rights to
access the information via eID) of the end user who requests data.
4. The information according to paragraph 1 of this Article 5 is to be shared via the
National Contact Points for eHealth, which are responsible for the proof of authenticity of
origin and content of ePrescriptions. At European level National Contact Points for eHealth
are responsible to their counterparts for the faithful representation of the information
provided by them. To this end National Contact Points for eHealth shall implement audit
trails.
Article 6: Patient safety
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Chapter III – Organisational Considerations
Article 7: Enablers for implementation
1. The rules of the dispensing Member State shall apply; hence Member States are
responsible for application of their rules regarding substitution.
2. It is acknowledged that the rules for substitution are outwith the remit of the eHealth
Network.
3. National legislation applies to the rules regarding storage of ePrescriptions.
8
Joint Action to support the eHealth Network
Article 8: Quality standards and validation
1. In order to assure safe implementation, particularly patient safety and data protection and
further development of cross-border services, in particular ePrescriptions, Member States
should:
(a) consider setting up a facility for cross-border ePrescription services to quality assure,
benchmark and assess progress on legal, organisational, technical and semantic
interoperability for their successful implementation;
(b) undertake assessment activities, such as measuring the quantitative and qualitative possible
benefits and risks (including economic benefits, risks and cost-effectiveness) of ePrescription
services.
Article 9: Education, training and awareness
1. In terms of education, training and awareness raising, Member States should:
(a) undertake common activities towards increasing awareness of the benefits of and need for
interoperability and related standards and specifications for ePrescription services, and for
electronic patient data exchange in general, including awareness of the need to foster the
interoperability of technical systems among producers and vendors of information and
communication technologies, health care providers, healthcare professionals, health
institutions, insurers and other stakeholders;
(b) consider recommendations for education and awareness raising measures targeting health
policymakers and health professionals/health care providers;
(c) pay particular attention to education, training and dissemination of good practices in
electronically recording, storing and processing prescription and medication data and other
patient information as well as in collecting informed consent of the patient and lawfully
sharing the patient's personal data;
(d) initiate appropriate, easy to understand information and awareness raising measures for all
individuals, in particular patients.
9
Joint Action to support the eHealth Network
Chapter IV – Semantic Considerations
Article 10: Data
1. Table 2 shows fields for the dataset. The data elements are taken from Implementing
Directive 2012/52/EU and Draft International Standard DIS 175233 published in June 2016.
Reference is also made to other relevant standards, including the ISO Identification of
Medicinal Products (IDMP) standards as referred to in the Implementing Directive. The data
elements ticked in the second column are mandatory; other elements are optional. Annex B.4
provides supporting information on each data field; further details will be added in future
releases of the guidelines.
2. ePrescriptions that contain data according to paragraph 1 of this Article 4, but that are not
ready for semantic interpretation by machines, may be rejected on grounds of patient
safety/national legislation.
Data Field ID
A.1 Core data elements
A.1.1 Identification of the patient
A.1.1.1 Surname [ISO TS 22220]
A.1.1.2 Given name [ISO TS 22220]
A.1.1.3 Date of birth [ISO TS 22220]
A.1.1.4 Personal identifier
A.1.1.5 Gender
A.1.2 Authentication of the prescription
A.1.2.1 Prescription ID
A.1.2.2 Issue date
A.1.3 Identification of the prescribing health professional
A.1.3.1 Surname
A.1.3.2 Given name
A.1.3.3 Professional qualifications
A.1.3.4 Details of direct contact
A.1.3.5 Work address
A.1.3.6 (Digital or electronic) signature
A.1.3.7 Health care provider identifier (HCPI)
A.1.4 Identification of the prescribed product4
A.1.4.1 Name of the item [+ identifier as described in ISO IS 11615]
A.1.4.2 Name of the item [+ identifier as described in ISO IS 11616]
A.1.4.3 Strength of the item [Article 1 of Directive 2001/83/EC]
A.1.5 Prescription information
A.1.5.1 Pharmaceutical dose form
A.1.5.2 Quantity
A.1.5.3 Dose regimen
A.1.5.4 Duration of treatment (start and/or stop time)
A.1.5.5 Directions for use
3
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=59952
4
The term product includes pharmaceutical products (branded medicinal products, generic/scientific name
medicinal products or pharmaceutical preparations [ISO 21549-7:2007]) and non-pharmaceutical products.
10
Joint Action to support the eHealth Network
A.1.5.6 Pharmaceutical preparation description5
A.2 Optional elements of prescription
A.2.1 Identification of the patient
A.2.1.1 Address details
A.2.1.2 Native language [could be taken from the ISO language table (ISO 639.2
or ISO 639-3)]
A.2.2 Patient characteristics
A.2.2.1 Body weight
A.2.2.2 Body height
A.2.2.3 Drug allergies and drug sensitivities
A.2.2.4 Patient conditions
A.2.3 Prescription information
A.2.3.1 Prescription expiry date
A.2.3.2 Repeats/refills
A.2.3.3 Minimum dispensing interval
A.2.3.4 Reason for prescription
A.2.3.5 Substitution handling
Table 2: ePrescription dataset
1. Prescription drugs may not be dispensed without appropriate identification of the
recipient, e.g. by inspection of the European Health Insurance Card of the citizen together
with photo ID.
2. Member States of treatment shall be responsible for communicating details of items
dispensed back to the originating country according to national laws. In the case of
eDispensations, the following data should be sent to the prescriber via the relevant eHealth
National Contact Point for the respective recipient (this should be done in real time and
immediately after the medicines have been dispensed):
1. Identification number of the dispenser
2. Name of dispenser
3. ISO 3166 country code of the dispenser
4. Address of the dispenser
5. Personal identification number of the patient, together with the ISO 3166 country
code
6. Identification number of the prescription
7. Items dispensed
8.
9.
Article 11: Terminology
10. There is a particular issue regarding the identification of medicinal products. It is expected
that the coding schemes currently included within the dataset will be replaced by identifiers
5
This also includes extemporaneous preparation, compounded medication and magistral preparation.
11
Joint Action to support the eHealth Network
developed using the IDMP set of standards. The European Medicines Agency is leading work
on this; further details will be provided in due course.
Article 12: Master Catalogue
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Chapter V – Technical Considerations
Article 14: Technical requirements
1. For cross-border exchange, the format of the document for exchange
will be the CEF specification, as shown in Annex B.5. Further work will be needed to review
this.
Article 15: Security
1. Member States shall ensure that communication of identifiable personal health data is
subject to secure communication and end-to-end security measures.
2. Member States shall assure logging of cross-border transactions and make logs available
for legal purposes, e.g. a health professional request for an ePrescription is important.
Article 16: Testing and audit
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 17: Amendments to the guidelines
The eHealth Network is responsible for updating the guidelines, which are addressed to
Member States.
12
Joint Action to support the eHealth Network
3. SUPPORTING INFORMATION
This chapter provides supporting information and explanatory text to aid understanding of
the guidelines, and the rationale behind the proposals. It therefore follows the same structure
as the general guidelines.
Chapter I – Scope and Definitions
Article 1: Objectives and scope
The guidelines will take a gradual approach to solving the interoperability issues inherent to
ePrescriptions, particularly at the semantic level (identification of drugs, information for
patients, drug use instructions) and for issues of substitution as a number of important
decisions are expected to be taken in the near future.
Article 2: Definitions
Formal definitions are provided in Article 2 in section 2 of these guidelines. However, it is
recognised that across Europe there are other terms for which different concepts apply;
examples include “primary care prescribing” and “substitution” (e.g. therapeutic, economic).
Article 3: Concept and intended use
The contents of these guidelines are seen as advice that will help each Member State to make
progress in terms of its own agenda.
Chapter II – Legal and Regulatory Considerations
Article 4: Data protection
Each query about the personal data available through cross-border services should be for a
real need for access to specific information related to an ePrescription or eDispensation
relating to the care or treatment to be provided.
Article 5: Authorisation, authentication and identification
Member States may wish to consider the content of a register of health professionals who are
entitled to prescribe and dispense, for instance:
(a) the name and profession,
(b) a personal identification number, including the ISO 3166 country code,
(c) the current address of the health care provider organisation with which the health
professional is affiliated or the address of his or her private practice,
(d) the date of issue of the healthcare professional’s licence to practice,
(e) the speciality might be recorded since the prescribing of some medicinal products may be
restricted.
Member States will need to consider their approach to implementing digital signature services
at the eGovernment or eHealth service level in the light of the electronic identification and
trust services (eIDAS6) regulation adopted in July 2014.
6
http://ec.europa.eu/digital-agenda/en/trust-services-and-eid
13
Joint Action to support the eHealth Network
To be able to link patients with their patient records, the existence of a patient identifier is
necessary. For cross-border purposes, a unique patient identifier is also a necessary
requirement for each individual patient to be linked to the patient record in the country of
origin. Analysis of data shows that most Member States already have a national patient
identification number available. In some cases Member States have a regional patient
identification number.
Article 6: Patient safety
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Chapter III – Organisational Considerations
Article 7: Enablers for implementation
There is no common definition, process or set of rules across Europe regarding the
substitution of medication. In order to aid discussion, the following definition might be used:
“Generic substitution” occurs when a different presentation of the same drug is substituted.
Usually, generic versions of a drug are considered by the licensing authority to be equivalent
to each other and to the originator drug. 7
The Horizon 2020 OpenMedicine project is investigating the issues around substitution and
is expecting to make recommendations on the topic. OpenMedicine has found no evidence
of therapeutic substitution.
For the purposes of these guidelines, it is recognised that substitution is not within the scope
of the eHN other than in enabling appropriate information exchange to support the agreed
policy.
Within a Member State, national dispensing rules shall apply. Most Member States, but not
all, allow generic substitution. For cross-border purposes, it is assumed that the rules of the
country where the dispensation is made should be accepted by the prescribing country. This
issue will need to be worked out for clarification of the consequences for both sides and
proposed in the next version of the guidelines. In formulating these guidelines, some guiding
principles have been proposed. Member States may wish to consider these:
For the countries which do not allow generic substitution or for countries which have put specific
limitations on generic prescriptions, it is thus advisable to allow for substitution of package size and/or brand
name in these situations:
in the event of shortages in the pharmacy, where the prescribed product is not available in the country,
urgency: if the product is available in the country but the pharmacist does not have it at that moment and
the patient needs it urgently,
if the brand name or size is not authorised or commercially available in country B, or
if the rules of substitution in country B force the change to be made.
7
Some exceptions might apply such as for biologics, biosimilars, drugs with a narrow therapeutic index and
non-interchangeable modified release preparations.
14
Joint Action to support the eHealth Network
In such cases, Country B will decide the brand name or package size to be dispensed according to its own
rules of substitution8.
There is no EU-wide agreement on minimum storage duration for ePrescription and
eDispensation records but the following proposals may be considered:
a) ePrescriptions and personal data concerning dispensation of these ePrescriptions shall be kept for a
minimum period of 24 months.
b) Data according to point a) above shall not be kept for more than 10 years, unless demanded by patients
or required by law, e.g. as part of a patient electronic record, in particular for the establishment, exercise or
defence of legal claims.
c) Data in the log files is to be stored for the purposes of the cross-border exchange and for litigation purposes
up to a maximum of 10 years.
Most of the Member States allow ePrescriptions to accommodate multiple dispensations for
multiple drugs. There is, however, a gap in code systems able to represent medications with
multiple active ingredients.
Member States of treatment shall be responsible for communicating back dispensation in line
with the fields identified in Article 5. These may be sent in the form of an XML message.
Article 8: Evaluation and quality assurance
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 9: Education and awareness raising
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Chapter IV – Semantic Considerations
Article 10: Data
Semantic interoperability requires representing the meaning of clinical information in
standardised ways that allow both humans and computers to understand clinical information.
An underlying principle is that exchange mechanisms convey both meaning and context.
The guidelines represent initial agreement on a Europe-wide prescription and dispensation
dataset, aligned with Implementing Directive 2012/52/EC. The aim of the dataset is to
support cross-border care. However, the ability to populate this dataset requires national
activity. More advanced and elaborate ePrescriptions exist in some Member States, but the
eHealth Network has agreed that the guidelines could serve as a common baseline for
ePrescriptions at national level.
The dataset in these guidelines is based on Implementing Directive 2012/52/EU and ISO
DIS 17523. Annex B.4 gives supporting descriptions of the data items together with a
summary of lessons learned from epSOS pilot sites. DIS 17523 is currently under ballot and
may be subject to change, but this could be reflected in the next release of these guidelines.
Article 11: Terminology
8
As footnote 18
15
Joint Action to support the eHealth Network
There is a particular issue regarding the identification of medicinal products. The European
Medicines Agency (EMA) has suggested the use of the inventory of medicines established
under the legal obligations laid down in Article 57 (2) of Regulation (EU) No 1235/2010 of
the European Parliament and of the Council of 15 December 2010 amending, as regards
pharmacovigilance of medicinal products for human use, Regulation (EC) No 726/2004
laying down Community procedures for the authorisation and supervision of medicinal
products for human and veterinary use and establishing a European Medicines Agency
(“pharmacovigilance legislation of 2010”)9: the so-called ‘Article 57 database’. EMA has also
suggested, in agreement with the National Regulatory Agencies, to start the aforementioned
use when the ISO IDMP adoption process reaches a significant level of completion. Member
States will work with the EMA and the European Commission to progress this.
Section 6 provides a possible formulation for the revised medicinal product information.
Article 12: Master Catalogue
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Chapter V – Technical Considerations
Article 13: Technical requirements
These guidelines focus on the content issues and the description of possible ways to produce
this content for cross-border exchange, taking into consideration existing national
implementations.
As electronic medication services take place in the field of public health and in accordance
with Article 11 of Directive 2011/24/EU, the goal must be to use open standards wherever
possible.
The fundamental requirement for exchange of information is to use a structured approach to
the recording of information.
Article 14: Security
There being no specific additional requirements, reference is made to the provisions defined
in the general guidelines.
Article 15: Testing and audit
Member States will need to implement software to support cross-border exchange. One
option would be to re-use the Open Source components maintained by the OpenNCP
community under the eHDSI. These components can be adopted by participating nations
and system integrators to build their own EHNCP solution.
To assure high-quality, safe and secure cross-border implementation, it will be necessary for
Member States to agree on testing strategies, possibly with a Europe-wide testing facility.
9
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:348:0001:0016:EN:PDF
16
4. EPRESCRIPTION DATASET
This section provides further information on the data items in the proposed dataset as well as a number of comments based on MS’ experiences.
Fields Field description
A.1 Core data elements
A.1.1 Identification of the patient
A.1.1.1 Surname Surname of the patient. The part of a name a person usually has in common with some other members of his/her family, as
distinguished from his/her given names [ISO TS 22220].
A.1.1.2 Given name (7) Given name of the patient (also known as first name). The subject's identifying name(s) within the family group or by which
the subject is uniquely socially identified [ISO TS 22220].
A.1.1.3 Date of birth (8) The date of birth of the patient [ISO TS 22220]. This can be the date of birth and/or the actual age of the patient. Since age
affects drug ADMET (absorption, distribution, metabolism, excretion and toxicity) parameters, this is important for the choice
of drug and drug dosage.
A.1.1.4 Personal A machine-readable identifier of the patient that is unique within a defined scope.
identifier
A.1.1.5 Gender (9) Gender is the biological distinction between male and female [ISO TS 22220]. The gender of the patient may be noted on
the prescription since this can be important for gender specific effects of drugs, contra-indications etc.
A.1.2 Authentication of the prescription
A.1.2.1 Prescription ID A unique string generated by an EPS (Electronic Prescribing System) to uniquely identify a prescription; this unique code is
needed for traceability. It might be used to register whether a prescription, and/or the maximum number of repeats, has already
been dispensed.
A.1.2.2 Issue date The date and optionally the time the prescription was issued. The date and time should be known in order to be able to conduct
checks on medication safety as well as reimbursement of the prescribed drug(s) and whether the prescription is still valid to
trigger a dispensing event.
Joint Action to support the eHealth Network
A.1.3 Identification of the prescribing health professional
A.1.3.1 Surname The prescription should state the family name/surname/last name of the prescriber. This enables the prescriber to be traced in
the event of questions or emergencies.
A.1.3.2 Given name The prescription should state the given name/first name of the prescriber. This enables the prescriber to be traced in the event
of questions or emergencies.
A.1.3.3 Professional The professional title of the prescribing health professional which may be used to prove the authority of the prescriber.
qualifications Note: in some countries, a nurse or midwife might not possess a professional title, but may still be entitled to prescribe (certain)
drugs.
A.1.3.4 Details of direct Details of direct contact could be an address and/or phone/fax number of the prescriber in order for the dispenser and/or
contact patient to contact the prescriber. This might be necessary if problems arise with dosage, allergies, reimbursement etc.
A.1.3.5 Work address This is the address of the hospital or the private practice where the health professional normally works, meets patients and
prescribes medication.
A.1.3.6 (Digital or Most countries require by law either a handwritten signature or a digital token as proof of the authenticity of the prescriber. A
electronic) signature digital signature is an approved authentication token necessary to comply with national laws on prescribing medicines. A
prescribing message or document without this signature can only be regarded as a notice of the actual (paper) prescription.
A.1.3.7 Health care A unique number or code issued for the purpose of identifying a health care provider [ISO/TS 27527:2010]; this may be a
provider identifier (HCPI) licence or registration number which can be used to trace the prescriber and to check whether a drug was prescribed by the right
person according to the law.
A.1.4 Identification of the prescribed product
A.1.4.1 Name of the An identification of the medicinal product [i.e. any substance or combination of substances that may be administered to human
item beings for treating or preventing disease, with a view to making a medical diagnosis or to restore, correct or modify physiological
functions] that is prescribed to the patient. In addition, information may be included regarding the possibility to replace the
prescribed product with an equivalent alternative.
Note: the term product includes pharmaceutical products (branded medicinal products, generic/scientific name medicinal
products or pharmaceutical preparations [ISO 21549-7:2007]) and non-pharmaceutical products.
A.1.4.2 Identifier of the Medicinal product manufactured in a pharmacy or pharmacy department which is based on a recipe and is intended to be used
item for one and only one subject of care [ISO 21549-7:2007].
Note 1: a magistral/extemporaneous medicinal product is also a pharmaceutical product.
Note 2: the term extemporaneous medicinal product is not to be used, as it is more appropriate for describing a medicine
processed during the administration of a medicinal product, especially when a mixture is made just before, for example,
intravenous administration. Information about the constituent ingredients if the prescription concerns an extemporaneous
18
Joint Action to support the eHealth Network
preparation or compound medicine.
A.1.4.3 Strength of the The content of the active substances expressed quantitatively per dosage unit, per unit of volume or weight according to the
item dosage form [Article 1 of Directive 2001/83/EC].
Note: strength of the medicinal product may also be derived from the element ‘dose regimen’. If for example the prescription
contains a statement such as ‘take 10mg 3x daily for 9 days’ the strength can be derived from this. In such circumstances,
strength may not be provided separately.
A.1.5 Prescription information
A.1.5.1 Pharmaceutical The formula in which the prescribed medicinal product is/will be administered (e.g. tablet, solution, ointment)
formulation
A.1.5.2 Quantity Total quantity or volume of the medicinal product that is prescribed
Note 1: in some cases quantity might be derived from element 1.5.3 Dose regimen. In this case, the quantity does not need to be
stated separately.
Note 2: depending on national legislation, this quantity may or may not be dispensed in one dispensation.
A.1.5.3 Dose regimen The regimen governing the dose quantity per single administration, the dose frequency, the route of administration and/or speed
of administration (in the event of intravenous administration).
Note: this information may be used by the dispenser to calculate the quantity to be dispensed.
A.1.5.4 Duration of Start and/or stop time of treatment
treatment
A.1.5.5 Directions for Information about the directions for use of the prescribed medicinal product (such as ‘with food’ or ‘before a meal’) and any
use cautionary advice for correct use of the prescribed drug by the patient
A.1.5.6 Pharmaceutical This also includes extemporaneous preparation, compounded medication and magistral preparation.
preparation description
A.2 Optional elements of prescription
A.2.1 Identification of the patient
A.2.1.1 Address details The address details of the patient
A.2.1.2 Native language (10) The native language of the patient. This may be important for the information that is given to the patient regarding use
[from the ISO language of the prescribed product [N1228 ISO NP TS 17251]. This could be taken from the ISO language table or another language
table (ISO 639.2 or ISO specification code system.
639-3)]
19
Joint Action to support the eHealth Network
A.2.2 Patient characteristics
A.2.2.1 Body weight The weight of the patient. This can be important for calculating the BMI used for dosage calculation, e.g. oncology medication,
or also body surface for other specific medications; this will need to specify units of measure.
A.2.2.2 Body height The height of the patient. This can be important for calculating the BMI as above.
A.2.2.3 Drug allergies Information regarding allergies and sensitivities to medicinal products (e.g. certain antibiotics), drug groups and both active and
and drug sensitivities non-active ingredients may be noted.
A.2.2.4 Patient Conditions that affect the use of medicinal products, such as renal/hepatic failure, pregnancy and pharmacogenetic profile.
conditions Some medicinal products may alter fertility, harm an unborn child or affect a child via breastfeeding. This may result in another
(type of) medicinal product being dispensed and/or modification of the dosage regimen. This may also be important when the
person is intending to become pregnant.
Note 1: in some countries a change of the medicinal product or modification of the dosage regimen does not lie within the
competence of the dispenser; Note 2: in some cases the effect on fertility or pregnancy has not yet been scientifically established.
A.2.3 Prescription information
A.2.3.1 Starting date of The time and date on which it is agreed that therapy will start
therapy
A.2.3.2 Prescription The date and optionally time when the prescription is considered to have expired. This might be dependent on local or national
expiry date policy or legislation, in accordance with the treatment plan or because the therapeutic need for the prescribed medicine has
expired.
A.2.3.3 Repeats Whether an issued prescription allows for several repeating dispensations [5]. In some countries, when medicinal products are
dispensed for the first time, the patient may only receive medication for a short period of time. When a patient starts taking
medication for a chronic illness, the prescriber can issue a prescription for a longer period that is now separated by repeats. In
addition, the maximum quantity (A.1.4.3) of the prescribed product that may be dispensed in one dispensation may be stated
here.
A.2.3.4 Minimum If an issued prescription allows for several repeating dispensations (A.1.4.6), the minimum time interval between dispensations
dispensing interval should be stated here [e.g. 5]. This can be important in the case of medicinal products of which patients are prone to take
overdoses, e.g. opioids.
A.2.3.5 Reason for The reason why the medicine is being prescribed, including the option to mention that the medicinal product is being prescribed
prescription for ‘off label’ use. The reason for the prescription gives the dispenser the opportunity to review the prescription for medication
safety issues.
Note: in some countries it is obligatory to state the reason for prescription on the prescription itself for some or all medicinal
products.
20
Joint Action to support the eHealth Network
A2.3.6 Substitution Substitution handling can be recorded as a code (not a flag!) to indicate whether and to what extent substitution is allowed by the
prescriber.
Table 3: ePrescription dataset with further information on data items in the proposed dataset including comments based on MS’ experiences
21
5. STANDARDS AND PROFILES
This section provides reference information on standards and profiles.
Reference is made to three classes of material:
Background requirements and explanatory material
https://ec.europa.eu/cefdigital/wiki/x/30QZAg
Formal technical and semantic specifications
https://ec.europa.eu/cefdigital/wiki/x/30QZAg
Formal terminology bindings
https://ec.europa.eu/cefdigital/wiki/x/30QZAg
ISO Identification of Medicinal Products (IDMP) standards
ISO 11615:2012 - Identification of medicinal products -- Data elements and structures for
the unique identification and exchange of regulated medicinal product information
(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55034)
ISO 11238:2012 - Identification of medicinal products -- Data elements and structures for
the unique identification and exchange of regulated information on substances
(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55031)
ISO 11616:2012 - Identification of medicinal products -- Data elements and structures for
the unique identification and exchange of regulated pharmaceutical product information
(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55035)
ISO 11239:2012 - Identification of medicinal products -- Data elements and structures for
the unique identification and exchange of regulated information on pharmaceutical dose
forms, units of presentation, routes of administration and packaging
(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55032)
ISO 11240:2012 - Identification of medicinal products -- Data elements and structures for
the unique identification and exchange of units of measurement
(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55033)
eHealth Network
6. POTENTIAL REFORMULATION OF MEDICINAL PRODUCT INFORMATION
A.1.4 Identification and description of the prescribed product 10
A.1.4.1 Pre-IDMP identification of the product as originally prescribed in the national
prescription note 1
A.1.4.1.1 Product name
A.1.4.1.2 Substance name
A.1.4.1.3 Strength of the item [Article 1 of Directive 2001/83/EC]
A.1.4.1.4 Pharmaceutical dose form11
A.1.4.2 IDMP identification of the product note 2
A.1.4.2.1 Identification of the packaged product as per ISO IS 11615
A.1.4.2.1.1 Identifier PCID (as issued by EMA) and code system
A.1.4.2.1.2 Name
A.1.4.2.2 Identification of the medicinal product as per ISO IS 11615
A.1.4.2.2.1 Identifier - MPID (as issued by EMA) and code system
A.1.4.2.2.2 Name
A.1.4.2.3 Identification of the pharmaceutical product as per ISO IS 11616
A.1.4.2.3.1 Identifier - PhPID (as issued by EMA) and code system
A.1.4.2.3.2 Name
A.1.4.2.4 Identification of the substance as per ISO IS 11238
A.1.4.2.4.1 Substance identifier (as issued by EMA or another authority) and code
system
A.1.4.2.4.2 Name
A.1.5 Characteristics of the product (for purposes of identification or finding
equivalents, etc.)
A.1.6 Prescription information
A.1.6.1 Administrable dose form12
A.1.6.2 Quantity
A.1.6.3 Dose regimen 1..N
A.1.6.4 Duration of treatment (start and/or stop time)
A.1.6.5 Directions for use
A.1.6.6 Pharmaceutical preparation description
Table 4: Potential reformulation of medicinal product information
Note 1: Product name and substance should be used until such a time as the ISO IDMP
identifiers are available. After the implementation of the IDMP, these identifiers may be
preserved but must be complemented with the IDMP identifiers.
Note 2: At least one of the IDMP identifiers should be available. The identifier is needed and the
name is optional.
10
At least one of the IDMP identifiers MUST be available, and possibly the national identifier.
11
This is the form in which the product is available commercially.
12
This is the form in which the product is supposed to be administered. It may differ from the pharmaceutical
dose form.
23
Ref. Ares(2017)3033026 - 16/06/2017
eHealth Network
eHealth Network
Guideline on an Organisational Framework for eHealth
National Contact Point
eHealth Network
The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth. The
Joint Action supporting the eHealth Network (JAseHN) provides scientific and technical
support to the Network.
Adopted by consensus by the eHealth Network, Brussels, 23 November 2015
eHealth Network
TABLE OF CONTENTS
I. Introduction................................................................................................................................................................ 4
1.1 Purpose of this document ................................................................................................................................. 5
1.2 Scope .................................................................................................................................................................... 5
1.3 Objectives ............................................................................................................................................................ 6
1.4 Time frame .......................................................................................................................................................... 6
1.5 Initial considerations .......................................................................................................................................... 7
II. National Contact Points for eHealth (NCPeH) ................................................................................................10
III. Organisational Framework for eHealth NCP ..................................................................................................11
3.1 Principles............................................................................................................................................................11
3.2 Organisational Framework .............................................................................................................................12
3.2.1 Set-up of an NCPeH ................................................................................................................................12
3.2.2 Core characteristics of an NCPeH .........................................................................................................13
3.2.3 General responsibilities and duties of an NCPeH...............................................................................13
3.2.4 Interaction between NCPeH and with EU core services ..................................................................14
3.2.5 NCPeH security policy ............................................................................................................................14
IV. Compliance establishment process ....................................................................................................................14
4.1 Rationale ............................................................................................................................................................14
4.2 Process for Member State Service Operation Audit...................................................................................15
4.3 Decision to admit a NCPeH to join the CBeHIS .......................................................................................17
4.4 Supporting tools and mechanisms .................................................................................................................18
4.4.1 Preparation.................................................................................................................................................18
4.4.2 Deployment ...............................................................................................................................................18
4.4.3 Operation ...................................................................................................................................................19
V. Closing remarks ......................................................................................................................................................19
VI. Appendices ............................................................................................................................................................21
6.1 Appendix A: Glossary ....................................................................................................................................21
6.2 Appendix B: Definitions ................................................................................................................................22
6.3 Appendix C: References .................................................................................................................................24
6.4 Appendix D: Semantic requirements and specifications ..........................................................................25
VII. Annexes ................................................................................................................................................................26
7.1 Annex A: Security policy ................................................................................................................................26
eHealth Network
Index of figures
Figure 1 – Resulting eHealth EIF structure .......................................................................................................... 7
Figure 2 – OFW-NCPeH alignment with related instruments........................................................................... 7
Figure 3 – Alignment of CBeHIS instruments and work in progress .............................................................11
Figure 4 – CBeHIS basic architectural elements ................................................................................................12
Figure 5 – Compliance establishment process ....................................................................................................16
Figure 6 – PDCA iterative management method ...............................................................................................17
Index of tables
Table 1 - NCPeH perspective on the eHealth EIF .............................................................................................. 8
Table 2 - Compliance establishment process - Stage 1: Preparation - tools and mechanisms.....................19
Table 3 - Compliance establishment process - Stage 2: Deployment - tools and mechanisms ...................20
Table 4 - Compliance establishment process - Stage 3: Operation - tools and mechanisms .......................20
eHealth Network
I. Introduction
One of the main challenges in supporting the eHN (eHealth Network) ambitions for
sustainability policies regarding assets in the field of eHealth cross-border interoperability is the
bond between policies and service provision by Member States (MS).
In order to establish the bond and allow it to grow and endure, a set of simple but well-aligned
instruments needs to be prepared. One of the crucial instruments is an Organisational
Framework which describes, in a commonly understandable language, the principles and
requirements for National Contact Points for eHealth (NCPeH).
The Cross Border eHealth Information Services (CBeHIS) mean the infrastructure and the
operations used to exchange of real patient related data, in particular health data, between its
members.
1.1 Purpose of this document
Propose an Organisational Framework guideline to support the governance, establishment and
operation of NCPeH towards the provision of Cross-Border eHealth Information Services
(CBeHIS).
The main architectural element of the Organisational Framework is the National Contact Point
for eHealth (NCPeH). These NCPeH constitute the country’s communication gateway that
assures the interface, not only technical, between the National Infrastructure and the EU network
of other Member States’ NCPeH, as well as with the central EU services.
Under the eHealth Digital Services Infrastructure (eHDSI) terminology, the provision of generic
services in the Member State mean the preparation, setting-up, deployment and operations of the
National Contact Point for eHealth (NCPeH) for the Cross Border eHealth Information Services
(CBeHIS).
The core services, to be provided by the European Commission, refer to those services that are
necessary at EU level for the CBeHIS.
1.2 Scope
The Guidelines on the Organisational Framework for NCPeH (OFW-NCPeH) were prepared in
close alignment with several activities taking place in the same time frame, namely:
European guidelines on Patient Summary (2013) and ePrescriptions (2014)
The Multilateral Legal Agreement (MLA) prepared by the eHN Legal Subgroup (LSG)1;
The CEF eHealth DSI call for proposals preparation;
The EXPAND revision of organisational, semantic and technical requirements and
specifications;
Other JAseHN task forces, namely the ones preparing the:
1 After the 8th eHN meeting on 23 November 2015, the eHN LSG will be merged with JAseHN as task 6.2
eHealth Network
o D5.1.2 Country guide for implementation of eHealth NCP
o D5.6.1 Assess MS technical readiness
o D5.6.2.1 Annual report on operational support for OpenNCP usage
The Patient Registries Joint Action.
The OFW describes the set-up requirements, core characteristics, responsibilities and duties of an
NCPeH, taking into consideration the crucial role played in the MS towards CBeHIS provision.
These are not exclusively limited to well-established use cases such as the Patient Summary and
ePrecription/eDispensation (eP/eD), but can also serve others that may be formalised by eHN
with possible necessary adaptations.
1.3 Objectives
Provide an Organisational Framework for the eHealth NCP, addressing the key stakeholders'
mandates and responsibilities:
set organisational principles and requirements towards the establishment of the National
Contact Point for eHealth,
present a process to guide MS along the path of “Preparation; Deployment; and
Operation” of CBeHIS,
stress the the relationship with EU level coordination, which governs the access to the
EU network and sets the requirements for compliance (legal, organisational, semantic
and technical).
1.4 Time frame
This document’s life cycle takes into consideration the following major milestones:
eHealth Network (approval for adoption mechanism)
o Adoption: 23 November 2015;
o Revision: November 2017, open for minor revisions in 2016.
CEF eHealth DSI2 (possible financing mechanism):
o Call for publication: November 2015;
o Deadline for proposal: March 2016;
o Grant agreements: by December 2016;
o Start of activities: towards the end of 2016.
2 Information kindly provided by SANTE D3 – eHealth and HTA Unit on 10 September 2015
eHealth Network
1.5 Initial considerations
This proposal for an OFW-NCPeH was designed on the basis of the European Interoperability
Framework (EIF). Future updates and revisions will take into consideration the ReEIF (Refined
eHealth European Interoperability Framework).
Figure 1 – Resulting eHealth EIF structure3
The OFW-NCPeH focuses as much as possible on the organisational principles and
requirements and is in alignment with several other important arrangements that have been
prepared by other projects (e.g. Antilope, EXPAND, epSOS, eHN LSG).
Figure 2 – OFW-NCPeH alignment with related instruments
Figure 2 provides a better understanding of how the OFW-NCPeH suits the eHealth EIF and
how it interacts with several other arrangements taking place.
3 DG CONNECT eHealth EIF – D3 Vision on eHealth EIF, Version 1.2 14 February 2013
eHealth Network
Table 1 - NCPeH perspective on the eHealth EIF
eHealth EIF OFW-NCPeH perspective
PRINCIPLES The overarching principles are defined by Directive
2011/24/EU
The eHealth Network established under the Directive adopts
all guidelines applicable to the CBeHIS and NCPeH.
Interoperability level: legal The Legal principles and requirements applied to CBeHIS will
be stated and described in the Multilateral Legal Agreement
(MLA) being prepared by the eHN Legal SG
Interoperability level: organisational The OFW-NCPeH provided in this document is the core
instrument for this interoperability level regarding CBeHIS.
Interoperability level: semantic The Master Value Set Catalogue (and Master Translation
Catalogue) as well as the semantic catalogues' governance
procedures are the key aspects at this interoperability level
regarding CBeHIS.
Interoperability level: technical The technical specifications and OpenNCP4 reference
implementation are the key aspects at this interoperability
level regarding CBeHIS.
Coordination mechanism at EU level The OFW-NCPeH stresses the relationship with the EU level
coordination mechanism and its role for setting the
compliance requirements and grant access to the CBeHIS.
The coordination mechanism is described in the document on
Governance model for the eHealth Digital Service
Infrastructure during the CEF5
Interoperability guidelines The OFW-NCPeH takes into consideration the following
eHN guidelines:
EU Patient Summary Guidelines
EU ePrescription Guidelines
Use cases (CBeHIS) Within the scope of the OFW-NCPeH, the use cases taken
into consideration are the:
Patient Summary
ePrescription (eDispensation)
Other use cases may be added by the eHealth Network later6.
Since several instruments are being prepared, matured and delivered simultaneously, it is expected
that some overlaps and gaps may require further attention in their revised versions to ensure that
the components are a perfect fit for each other.
4 For more information about OpenNCP, please see https://openncp.atlassian.net/wiki/
5 To be adopted by the eHealth Network 23 November 2015.
6 Such as the Patient Registries and European Reference Networks.
eHealth Network
Namely, there was initially a significant overlap between the MLA (being prepared by the eHN
Legal SG) and the OFW-NCPeH (prepared by JAseHN T5.1). Although most of the issues that
overlap have been identified and sorted out to differing extents, the current version may require
fine-tuning and further enhancements to guarantee that all principles and requirements are
correctly addressed in accordance with each specific instrument.
On the other hand, there is the need for a clear perspective on how the OFW-NCPeH will
connect with other instruments such as the JAseHN T5.1 and T5.6 deliverables:
D5.1.2 Country guide for implementation of eHealth NCP;
D5.6.1 Assess MS technical readiness;
D5.6.2.1 Annual report on operational support for OpenNCP usage.
The JAseHN deliverables listed above need a clear mandate on how to build on the EXPAND
work in progress and monitor possible or potential duplications of effort in order to avoid
content overlaps.
In this way, as shown in the following figure, the JAseHN deliverables will focus on aligning the
usage of the technical instruments provided by EXPAND7, according to relevant OFW-NCPeH
compliance establishment processes (explained in section IV. Compliance establishment process)
and guidelines.
Figure 3 – Alignment of CBeHIS instruments and work in progress
7 Likewise, EXPAND WP 5 Deployment Shop may further explore, from 24 November 2015 until the end of the
project (31 December 2015), some concrete challenges and mechanisms for deploying the OFW-NCPeH in each
MS.
eHealth Network
II. National Contact Points for eHealth (NCPeH)
MS that have previously experienced CBeHIS (pilots or real/live services) have shown that it is
necessary for MS to set up a National Contact Point for eHealth (NCPeH).
Each MS needs to organise/set up one NCPeH to act as a communication gateway with other
MS and also as a mediator for delivering services.
As such, an NCPeH should be identifiable in both the EU domain and its national domain, and
remain an active part of the CBeHIS environment if compliant with the legal, organisational,
semantic and technical requirements.
The NCPeH should also act as an interface with existing national infrastructures.
The provision of generic services in the Member State under the eHDSI mean the
preparation, setting-up, deployment and operations of the NCPeH for CBeHIS.
The following diagram demonstrates the basic elements of the CBeHIS environment.
Figure 4 – CBeHIS basic architectural elements
The core characteristics, responsibilities and duties of the NCPeH (and its national partners,
where applicable) are presented in these Organisational Framework guidelines, so that the
NCPeH, once established, may enter into agreements on a common basis to deliver CBeHIS to
patients.
The NCPeH profile is quite different (e.g. different services provided, different entity, different
governance, different requirements) from the National Contact Point described in Article 6 of
Directive 2011/24/EU. There is however some overlap concerning the obligation for provision
of information to patients with regard to the processing of their personal data (Patient
Information Notice) specific to their rights with respect to the Data Protection Directive.
eHealth Network
III. Organisational Framework for eHealth NCP
BASELINE CONSENSUS STATEMENT
This first version of the Organisational Framework for eHealth NCP (OFW-NCPeH) is considered by the
eHealth Network to be the foundational instrument for involving the National Authorities for Cross-
Border eHealth Information Services (CBeHIS) provision in the process of localising this blueprint in
their national reality.
Provision was made so that, after localisation is completed, this blueprint could be reviewed in terms of
the amendments needed to better match its European-wide application.
3.1 Principles
While the Multilateral Legal Agreement (MLA) sets overarching legal principles and
requirements, the Organisational Framework for NCPeH (OFW-NCPeH) provides
specific and commonly agreed organisational guidelines for the successful provision of
Cross-Border eHealth Information Services (CBeHIS).
This Organisational Framework (OFW) provides guidelines for coordination and
compliance mechanisms towards the provision of CBeHIS supporting patient care
delivery to European citizens outside their usual state of residence by means of a
shareable electronic Patient Summary and ePrescription.
These Organisational Framework for NCPeH (OFW-NCPeH) guidelines is the blueprint
which must be transposed into agreements at national level in so far as it is necessary to
comply with national laws or customs. It is imperative that EU level interoperability is
secured at all instances and times. This may be achieved by:
Ensuring that any additional requirements do not create conflicts with these
agreements;
Raising new issues identified in the process of their specific interest collaboration
for consideration and policy update at EU level;
Maintaining transparency within the framework of EU coordination mechanism.
This Organisational Framework for NCPeH (OFW-NCPeH) provides guidance and
requirements towards the following perspectives (further specified in section 3.2
Organisational Framework):
1. Definition of an NCPeH;
2. Core characteristics of an NCPeH;
3. General responsibilities and duties of an NCPeH;
4. Interaction between NCPeH and with EU core services.
The MLA handles patient consent principles and requirements.
eHealth Network
For health data to flow across borders, it is necessary to establish the required level of
compliance and trust to ensure that Health Professionals can rely upon the integrity of
the data that will support their decisions, that suitable systems of security exist to ensure
that data cannot be accessed by unauthorised parties, and that patients’ rights of informed
consent to data sharing are duly respected by all parties.
With respect to privacy and data protection, the principle of free movement of goods,
services and persons gives rise to the need to process personal data across borders.
Directive 95/46/EU regulates how personal data is processed in these cases with the aim
to protect personal integrity. While MS have all recognised data contained in medical
documentation as “sensitive personal data” subject to a higher level of protection, there is
broad national diversity in the way the Data Protection Directive has been implemented
in national provisions, which in some cases creates barriers to the free movement of data.
While the prospective data protection regulation and the eIDAS regulation in force and
their foreseen implementation may address some of the barriers identified (e.g. in the
epSOS Large Scale Pilot), there is a need for the eHealth Network to discuss and come to
an agreement on a number of common policies and measures concerning privacy and
security such as for identification and authentication, foreseen in Article 14 of Directive
2011/24/EU.
Until such common measures are sufficiently reflected in appropriate legal EU level
instruments, these may be expressed as requirements for countries to be addressed when
setting up their NCPs for eHealth.
3.2 Organisational Framework
3.2.1 Set-up of an NCPeH
3.2.1.1 MS participating in the CBeHIS should set up an NCPeH compliant with the OFW-
NCPeH. This should be unique to each MS in its relationship with other MS, i.e. a single
NCPeH communication gateway should be responsible for interaction with other MS
NCPeH communication gateways for cross-border services.
3.2.1.1.1 “Regional replicas” of both the technological and organisational arrangements of
a typical NCPeH, would constitute a Regional Contact Point (RCPeH), are possible and
follow the same principles and requirements.
3.2.1.1.2 If a MS has two or more Regional Contact Points, it needs to nominate one to
act as an NCPeH, to act as the national gateway vis-à-vis other MS.
3.2.1.2 Participating MS should make adequate arrangements to ensure NCPeH readiness for
operation of CBeHIS and level of service sustainability (by following the compliance
establishment process described in section 4.2 Process for Member State Service Operation
Audit).
3.2.1.3 The entry into operation of an NCPeH requires the explicit approval of the
coordination mechanism established for the CBeHIS environment.
3.2.1.4 Participating MS should establish NCPeH adequate monitoring procedures.
eHealth Network
3.2.1.5 It is recommended that national training materials and activities be provided to
support CBeHIS operation.
3.2.1.6 It is recommended that participating MS engage Health Professionals in specification
updates and other clinical concerns related to the operation of services.
3.2.1.7 It is recommended that participating MS inform citizens about CBeHIS provisions.
3.2.2 Core characteristics of an NCPeH
3.2.2.1 The NCPeH must establish the connection with the national infrastructure, ensuring
that appropriate processes and procedures are in place (security measures, safeguards etc.).
3.2.2.1.1 Describe national infrastructure with the purpose of interfacing (e.g.
services available, data sources).
3.2.2.2 The NCPeH must ensure that semantic transformation (e.g. translation and mapping),
which is needed for the cross-border information exchange, is performed according to the
semantic requirements and specifications provided in
eHealth Network
6.4 Appendix D: Semantic requirements and specifications.
3.2.2.2.1 The responsibility for the accuracy and integrity of the process is with each
national designated competent entity for such semantic processing.
3.2.2.2.2 Liability for errors in the semantic transformation will be described in the MLA.
3.2.2.3 The NCPeH must provide a gateway service, a request port and a semantic
transformation service in order to enable it to execute the core steps in the CBeHIS (e.g.
Patient Summary, ePrescription).
3.2.2.4 The MS must ensure that the NCPeH for the CBeHIS has clearly identified the
responsible data controller and data processor in accordance with the provisions of Directive
95/46 EU.
3.2.2.5 The NCPeH must ensure an auditing mechanism for legal, organisational, semantic
and technical requirements.
3.2.2.6 The NCPeH must enforce foreign patients’ identity validation of foreign patients.
3.2.2.7 The NCPeH must maintain the national versions of the controlled vocabularies used
in semantic transformation.
3.2.3 General responsibilities and duties of an NCPeH
3.2.3.1 The NCPeH shall establish appropriate security and data protection systems to
conform to CBeHIS requirements as well as all applicable national requirements.
3.2.3.2 The NCPeH shall take all reasonable steps to ensure data security (including data
confidentiality, integrity, authenticity, availability and non-repudiation).
3.2.3.2.1 The NCPeH shall enforce identity validation of Health Professionals that use
CBeHIS.
3.2.3.2.2 The NCPeH shall establish an appropriate system of audit trail, allowing
authorised official bodies to duly inspect the established mechanisms for data collection,
processing, translation and transmitting.
3.2.3.3 The NCPeH must ensure that CBeHIS data is not transmitted to MS not belonging or
allowed into the CBeHIS environment.
3.2.3.3.1 Non-EU countries may operate in line with the CBeHIS with the explicit
approval eHealth Network.
3.2.3.4 The NCPeH shall establish and maintain an incident management solution to support
Health Professionals, Healthcare Providers and citizens in its territory.
3.2.4 Interaction between NCPeH and with EU core services
3.2.4.1 The NCPeH must ensure the security (confidentiality, integrity, availability, non-
repudiation, authenticity and auditability) of data processed on their territory.
3.2.4.2 The NCPeH shall guarantee that all CBeHIS agreed service requirements and
specifications (legal, organisational, semantic and technical) are fulfilled.
eHealth Network
3.2.4.3 The NCPeH shall collaborate actively on the harmonisation of guidelines and
appropriate practices to facilitate the establishment of the CBeHIS environment.
3.2.4.4 The NCPeH shall adopt a national OFW-NCPeH on CBeHIS that comprise
commonly adopted policies, processes and audit mechanisms.
3.2.4.5 The NCPeH must ensure the appropriate interface with the core services set up at EU
level.
3.2.5 NCPeH security policy
3.2.5.1 Participating MS must ensure that they are fully compliant with the CBeHIS Security
Policy as set out in detail in 7.1 Annex A: Security policy.
3.2.5.1.1 The NCPeH Security Policy Baseline creates a general security and data
protection baseline adapted to CBeHIS needs.
3.2.5.1.2 The NCPeH Security Policy Baseline addresses all elements of data flows
in the CBeHIS, including national and cross-border data flows.
IV. Compliance establishment process
4.1 Rationale
The following Member State Service Operation Audit process, describes a method for ensuring
that NCPeH compliance can be established, maintained and reinforced through a pre-defined set
of activities and responsibilities, namely
a) The eHDSI governance structure can establish a peer-to-peer process to validate
organisational arrangements between MS and at EU level (core services);
b) Checking and endorsing NCPeH organisational readiness for starting operation of
CBeHIS;
c) Following up and endorsing developments in the MS after the initial audit.
d) Ensuring a level of service of the NCPeH during operation in the CBeHIS environment.
One of the key building blocks for OFW-NCPeH is the procedure through which the
coordination mechanism (explained in 4.3 Decision to admit a NCPeH to join the CBeHIS) and
the MS monitor progress regarding preparation, deployment and operation of cross-border care
services.
Lessons learnt from previous Cross Border eHealth Information Services (CBeHIS) initiatives
point to the following:
There must be an accession process for MS into the CBeHIS environment, with clear role
assignments, once all (Legal, organizational, Semantic and Technical) requirements have
been fulfilled and verified through interoperability testing, peer review and other
appropriate methods.
eHealth Network
This process shall allow for the contractual agreements established at national level to be
(peer) reviewed and assessed as compliant with MLA and OFW-NCPeH. This process
should consider international, well established principles of certification.
There must be a monitoring and support mechanism for ensuring continuing capacity
(comply with principles and requirements and perform according to expected service
level’s) to be part of the CBeHIS environment.
4.2 Process for Member State Service Operation Audit
The current process goal is to ensure that NCPeH compliance can be established,
maintained and reinforced.
The process is composed of three main stages:
PREPARATION, where MS design the national deployment plan and perform national
preparatory activities towards the provision of cross-border eHealth services;
DEPLOYMENT, where MS test (nationally and internationally), audit and provide
evidence of the readiness level towards the provision of services.
OPERATION, where MS provide evidence about the quality and level of service
provided, as well as Key Performance Indicators about service provision.
PREPARATION DEPLOYMENT OPERATION
Peer-to-Peer Audit
Figure 5 – Compliance establishment process
The goals defined for each stage may be supported by a set of tools and mechanisms that guide
MS towards each stage as well as providing evidence on the basis of which the governing body
may take decisions regarding “readiness level” and “quality of service”.
Preparation
Member State Service Deployment [PLAN]
Member State Requirements and Recommendations [CHECKLIST]
Member State Preparation Progress [REPORT]
eHealth Network
Deployment
Member State Service Readiness [CHECKLIST]
Member State Service Initial Audit [REPORT]
Operation
Member State Service Operation [PLAN]
Member State Service Operation Monitoring [REPORT]
Member State Service Operation Audit [REPORT, Peer-to-Peer Review]*
Member State Service Operation Evaluation [REPORT]
* Audits must be performed by third party entities. In order to promote knowledge exchange and
fluent convergence of practices between Member States, audits should be performed by peer
Member States that may already be in operation.
This principle should be understood as a continuous improvement mechanism according to the
PDCA (plan–do–check–act / plan–do–check–adjust) iterative four-step management method
that will boost quality and MS liaison towards the provision of CBeHIS.
Figure 6 – PDCA iterative management method
4.3 Decision to admit a NCPeH to join the CBeHIS
The eHealth Network has the broad mandate to (as stated in Article 14, 2011/24/EU):
“work towards delivering sustainable economic and social benefits of European eHealth systems and
services and interoperable applications, with a view to achieving a high level of trust and security,
enhancing continuity of care and ensuring access to safe and high-quality healthcare”.
The eHealth Network has a central role in coordinating eHealth-specific policy aspects within the
more general EU level governance for interoperability.
eHealth Network
The OFW-NCPeH requires that the coordination mechanism enforces the legal, organisational,
semantic and technical principles and requirements underlying an entry into operation in the
CBeHIS environment, the Coordination Function should be complemented by a Technical
Committee that would support the necessary MS compliance assessment.
The coordination mechanism should consider a steering group composed by MS representatives.
The eHealth Network takes the decision on admitting an NCPeH to join the CBeHIS, based on
the audit report.
eHealth Network
4.4 Supporting tools and mechanisms
4.4.1 Preparation
Table 2 - Compliance establishment process - Stage 1: Preparation - tools and mechanisms
DOCUMENT PURPOSE VALUE ADDED
Member State Service Allow the MS to share national vision Knowledge about MS aims and plans, in a
Deployment [PLAN] and intentions towards CBeHIS comparable structured way
provision
Member State Support the MS to set up and adopt Guide the MS on establishing the NCPeH
Requirements and measures required for the optimal
Recommendations establishment of the NCPeH
[CHECKLIST]
Member State Allow the MS to report on preparation of Knowledge about MS status, activities in
Preparation Progress NCPeH activities in a structured and progress and known issues
[REPORT] shareable way
4.4.2 Deployment
Table 3 - Compliance establishment process - Stage 2: Deployment - tools and mechanisms
DOCUMENT PURPOSE VALUE ADDED
Member State Service Measure and report MS readiness MS quantified readiness status for
Readiness regarding CBeHIS provision operating CBeHIS
[CHECKLIST]
Member State Service Verify NCPeH compliance with CBeHIS Evidence, provided by a third party, on
Initial Audit requirements (legal, organisational, MS readiness for operating CBeHIS
semantic and technical)
[REPORT]
eHealth Network
4.4.3 Operation
Table 4 - Compliance establishment process - Stage 3: Operation - tools and mechanisms
DOCUMENT PURPOSE VALUE ADDED
Member State Service Design and state MS intentions and Understanding practices and
Operation [PLAN] willingness towards CBeHIS provision, arrangements adopted by MS for keeping
as well as arrangements for keeping the level of service
level of service
Member State Service Provide an insight into the NCPeH Commonly agreed and structured way of
Operation Monitoring activities performed during the operation understanding the NCPeH level of service
period
[REPORT]
Member State Service Verify NCPeH compliance maintenance Evidence, provided by a third party, on
Operation Audit with CBeHIS requirements (legal, NCPeH compliance for operating
organisational, semantic and technical) CBeHIS
[REPORT]
during operation
Member State Service Measure and indicate the usage and Service provision impact and value added
Operation Evaluation impact achieved with CBeHIS provision, (e.g. for citizens and Health Professionals)
as well as known issues to be addressed and improvement opportunities
[REPORT]
and improved
V. Closing remarks
The current document represents the fundamental baseline for a rich and enduring
Organisational Framework for National Contact Points for eHealth (OFW-NCPeH).
At this point, the nature of the OFW-NCPeH represents a commitment based on lessons learnt
from previous Cross-Border eHealth Information Services (CBeHIS) initiatives and the
overarching perspective that will be established under the Multilateral Legal Agreement (MLA).
The current OFW-NCPeH:
sets organisational principles and requirements towards the establishment of the
National Contact Point for eHealth (NCPeH),
presents a process to guide MS along the path of “Preparation; Deployment; and
Operation” of CBeHIS,
stresses the need for a coordination function to act as an accession point regarding
requirements compliance (legal, organisational, semantic and technical).
The proposed OFW-NCPeH requires a coordination mechanism to be enforced. It is expected
that a coordination mechanism could be endorsed during the 8th eHN meeting.
The proposed OFW-NCPeH should be revised and enhanced, taking into consideration the
maturity and experience emerging from service provision.
eHealth Network
However, in order to fulfil the principle of governance stability, profound changes should not
occur before a 2-year (two-year) maturation cycle (by November 2017). Until then, enhancements
should focus on fine-tuning the OFW-NCPeH without touching the underlying principles and
requirements.
eHealth Network
VI. Appendices
6.1 Appendix A: Glossary
TERM DESCRIPTION
CBeHIS Cross-Border eHealth Information Services
CEF Connecting Europe Facility
DSI Digital Service Infrastructure
EC European Commission
eHDSI Term used for the generic and core services for the cross border services of eP and
PS during CEF financing
eHN eHealth Network
eHN-LSG eHealth Network Legal Subgroup
EIF European Interoperability Framework
EU European Union
IOP Interoperability
HP Health Professional
JAseHN Joint Action to support the eHN
LOST Legal, Organisational, Semantic, Technical
MLA Multilateral Legal Agreement
MS Member States (of EU)
NCP National Contact Point
NCPeH National Contact Point for eHealth
NI National Infrastructure
OFW Organisational Framework
OFW-NCPeH Organisational Framework for eHealth National Contact Point
PARENT JA Patient Registries Joint Action
PoC Point of Care
ReEIF Refined eHealth European Interoperability Framework
eHealth Network
6.2 Appendix B: Definitions
CONCEPT DEFINITION
CBeHIS Cross-Border eHealth Information Services within the scope of the current
document, namely Patient Summary and ePrescription (may include
eDispensation)
CBeHIS Stakeholders, relations between them and favourable infrastructures to allow
environment CBeHIS to flourish
CEF eHealth DSI EU financial (€7.5M) mechanism (based on call for proposals) that will be
launched by November 2015 and may be used by MS to support CBeHIS
provision (preparation, deployment and operation of NCPeH - meaning generic
services in CEF)
Communication MS system that manages CBeHIS transactions with other MS and which connects
gateway to the NI.
This is an entry/exit point from the MS, acting on behalf of a HP and citizen (at a
Point of Care), that ensures the exchange of the patient’s medical data in a
controlled environment.
Compliance A well-defined set of activities and evidence used to ensure that NCPeH
establishment compliance can be established, maintained and reinforced.
process
Country A The country of affiliation. This is the country that holds information about a
patient, where the patient can be unequivocally identified and his or her data may
be accessed.
Country B The country of treatment, i.e. the country where cross-border healthcare is
provided when the patient seeks care abroad.
Framework A real or conceptual structure intended to serve as a support or guide for the
building of something that expands the structure into something useful.
Guideline A suggested way of compliance when doing something. It is visible to those using
or supporting the use of a particular service but there are no sanctions if it is not
followed.
Guideline for Intended to present to the eHealth Network’s members a clear guideline, with the
adoption intention for it to be adopted and optionally implemented by the EU MS at
national level in the next step.
National The healthcare IT infrastructure, which manages patient and HP/HCP8
infrastructure identification and healthcare records in MS.
NCP National Contact Point as referred to in Article 6 of Directive 2011/24/EU
NCPeH National Contact Point for eHealth, which may act as an organisational and
technical gateway for the provision of eHealth Cross-Border Information Services
NCPeH Set of activities aiming to ensure NCPeH compliance with the full range of
8 see Article 3 (f) and (g) of Directive 2011/24/EU
eHealth Network
deployment requirements (LOST) established towards CBeHIS provision
NCPeH Process of preparing, deploying and operating an NCPeH
implementation
NCPeH operation Set of activities performed by the MS while providing services to citizens and
Health Professionals
NCPeH Set of activities aiming to set up an NCPeH
preparation
Organisational Defines core characteristics, duties and responsibilities of an NCPeH
Framework
PoC A location where an EU citizen may seek healthcare services. This may be a
hospital, pharmacy or any other facility in the healthcare system of Country B.
Requirement Definition of relevant needs (business, functional, non-functional, technical and
technological) for system specification and implementation
eHealth Network
6.3 Appendix C: References
This document is based upon several reference materials, beyond epSOS FWA, provided by
EXPAND and other EU eHealth projects. The following list provides an exhaustive
identification of the material considered until the present version of this document:
Framework Agreement on National Contact Points in the context of epSOS (epSOS
FWA)
epSOS Interoperability Framework and Key Interoperability Layers (D.3.3.3)
epSOS National Pilot Set Up and Deployment Guide (D3.8.2)
epSOS FINAL SECURITY SERVICES SPECIFICATION DEFINITION (D.3.7.2.),
namely SECTION III SUITABILITY ANALYSIS
epSOS Testing Methodology, Test Plan and Tools (D3.9.2)
epSOS Recommendations (D2.2.7)
Antilope Refinement Definition document (D1.1)
EXPAND Scope and transferability of key outcomes of epSOS and corresponding
actions for transferability and scale up (D5.1 Draft)
Project pilot tools that can be reshaped and adapted for large-scale services were also used and
enhanced, including:
epSOS Participating Nation Pilot Plan;
epSOS Requirements and Recommendations – Check List;
epSOS Participating Nation Member State Progress Report;
epSOS Participating Nation Initial Audit Report
epSOS D4.D.3 Report on readiness to pilot
eHealth Network
6.4 Appendix D: Semantic requirements and specifications
Provided by:
o GUIDELINES ON MINIMUM/NONEXHAUSTIVE PATIENT SUMMARY
DATASET FOR ELECTRONIC EXCHANGE IN ACCORDANCE WITH
THE CROSS-BORDER DIRECTIVE 2011/24/EU
o GUIDELINES ON ePRESCRIPTIONS DATASET FOR ELECTRONIC
EXCHANGE UNDER CROSS-BORDER DIRECTIVE 2011/24/EU
To be provided: EXPAND, a consolidated version of epSOS Semantic Requirements and
Specifications.
eHealth Network
VII. Annexes
7.1 Annex A: Security policy
1. Need and scope
Security is a critically important issue for CBeHIS. Without adequate security in place none of the CBeHIS can
be used in real-life environments. The CBeHIS Security Policy aims to create a secure operational environment for
the service deployment, which will be sufficient for protecting the CBeHIS data and processes, implementable and
agreed by all MS. The CBeHIS Security Policy provides a secure operational environment for CBeHIS and helps
develop a ‘chain of trust’ among CBeHIS actors. The CBeHIS Security Policy also specifies the requirements of
service providers and users and must be implemented and periodically audited by all CBeHIS actors, as described
below.
2. Principles
All CBeHIS data and processes must be adequately protected. The network built among the CBeHIS MS should
also not add any unacceptable new risk within any participating organisation. Appropriate technologies and
procedures must be used to ensure that data is stored, processed and transmitted securely over the network built
among the CBeHIS actors and is only disclosed to authorised parties.
Information security is generally characterised as the protection of:
a. Confidentiality (information is protected from unauthorised access or unintended disclosure – only
authorised users have access to the information and other system resources),
b. Integrity (information is protected from unauthorised modification) and
c. Availability (resources are available, without unreasonable delay - authorised users are able to access
information and the related means when they need it).
The CBeHIS Security Policy should help to ensure and enforce the above. It should also provide means of proof
and essential checks, which establish users’ trust in the given information.
3. Objectives
The objective of the CBeHIS Security Policy is to establish the basic security provisions that must be satisfied in
order to ensure the security of data and system continuity and to prevent and minimise the impact of security
incidents by implementing a stable, reliable and secure infrastructure.
More specifically, the CBeHIS Security Policy objectives are:
a. To make CBeHIS actors sensitive to the operated means of protection and the risks which they cover.
b. To create a general security framework adapted to the CBeHIS information system needs, which should
be observed by those in charge of CBeHIS processes; it should be implemented by putting in place
measures and procedures in order to ensure the CBeHIS information and CBeHIS information system
and infrastructure security.
eHealth Network
c. To promote cooperation between various CBeHIS actors in order to jointly elaborate and put in place
those measures, instructions and procedures.
d. To enhance user and patient trust in the information system.
e. To ensure that the information system in place respects national and European legislation on privacy and
data protection in force.
The CBeHIS security policy is constructed in line with the principle of a well-proportioned answer to the incurred
risk.
4. Security rules
To be adopted by the eHealth Network9.
9 The eHealth Network will consider them as soon as provided by JAseHN T5.1, they will have as foundation the
epSOS Security Policy, but will be curated (jointly with JAseHN T6.2) to be in perfect alignment with the MLA.
Ref. Ares(2017)3033026 - 16/06/2017
RECOMMENDATIONS
on
Country Guide for eHealth NCP implementation
Document Information:
For adoption by the members of the eHealth Network at their 9th
Document status:
meeting on 07 June 2016
Approved by JAseHN
Yes
sPSC
Document Version: v1.0
Document Number: D5.1.2
Joint Action to support the eHealth Network
Document produced by: WP5 Interoperability and Standardisation
T5.1 Trusted eHealth National Contact Points
Licinio Mano (SPMS), Lília Marques (SPMS), Justas Trinkunas
Author(s):
(VULSK)
Austria (ATNA), Finland (THL), France (ASIP, FRNA), Germany
Member State (GEMATIK), Greece (3DHHR), Hungary (ÀEEK), Ireland (DH),
Contributor(s): Lithuania (VULSK), Norway (HDIR), Portugal (SPMS), Sweden
(SeHA, SENA)
Stakeholder
Contributor(s):
Joint Action to support the eHealth Network
TABLE OF CHANGE HISTORY
VERSION DATE SUBJECT MODIFIED BY
0.1 2015-09-08 Basic draft document Licinio Mano (SPMS)
0.2 2015-09-15 TOC consolidated Licinio Mano (SPMS)
0.3 2015-10-14 Draft submitted “for review” by JAseHN Licinio Mano (SPMS)
SPSC
0.4 2015-09-21 Consolidation based on feedback gathered Licinio Mano (SPMS),
during formal QA review Justas Trinkunas
(VULSK)
0.5 2015-10-23 Draft submitted “for discussion” to the 8th Licinio Mano (SPMS),
EHN meeting on 2015-11-23 Justas Trinkunas
(VULSK)
0.6 2016-03-23 Review as per recommendations Justas Trinkunas
(VULSK)
0.7 2016-03-29 General review Lília Marques (SPMS)
0.8 2016-03-13 1st draft, submitted “for review” by JAseHN Licinio Mano (SPMS)
WP3
0.9 2016-05-10 Update annexes Lília Marques (SPMS)
0.10 2016-05-13 Overall document review with sPSC Licinio Mano (SPMS)
comments
1.0 2016-05-23 Submitted “for adoption” to the 9th EHN Licinio Mano (SPMS)
meeting in June 2016
2
Joint Action to support the eHealth Network
LIST OF ABBREVIATIONS
ACRONYM DEFINITION
CBeHIS Cross Border eHealth Information Services
CEF Connecting Europe Facility
DSI Digital Service Infrastructure
EC European Commission
eHDSI eHealth DSI
eHN eHealth Network
eHN-LSG eHealth Network Legal Subgroup
EIF European Interoperability Framework
EU European Union
IOP Interoperability
HP Health Professional
JAseHN Joint Action to support the eHN
LOST Legal, Organisational, Semantic, Technical
MLA Multilateral Legal Agreement
MS Member States (of EU)
NCP National Contact Point for cross-border services
NCPeH National Contact Point for eHealth
NI National Infrastructure
OFW Organisational Framework
OFW-NCPeH Organisational Framework for National Contact Point for eHealth
PoC Point of Care
ReEIF Refined eHealth European Interoperability Framework
PARENT JA Patient Registries Initiative Joint Action
3
Joint Action to support the eHealth Network
LIST OF TERMS AND DEFINITIONS
TERM DEFINITION
CBeHIS Cross Border eHealth Information Services in the scope of the current document,
namely Patient Summary and ePrescription (may include eDispensation)
CBeHIS Stakeholders, relations between them and favourable infrastructures to allow the
environment flourishing of CBeHIS
CEF eHealth DSI EU financial (€7.5 million) mechanism (based on call for proposals) that was
or eHDSI launched by November 2015 and may be used by MS to support CBeHIS
provision (Preparation, Deployment and Operation of NCPeH - meaning generic
services in CEF)
Communication MS system that manages CBeHIS transactions with other MS and which connects
Gateway to the NI.
This is an entry/exit point from the MS, acting on behalf of a HP and Citizen (at
a Point of Care), that assures the exchange of patient’s medical data in a
controlled environment.
Compliance A well-defined set of activities and evidence used to ensure that NCPeH
Establishment compliance can be established, maintained and reinforced
Process
Country A The country of affiliation. This is the country that holds information about a
patient, where the patient can be unequivocally identified and his/her data may be
accessed.
Country B The country of treatment, i.e. where cross-border health care is provided when
the patient is seeking care abroad.
Framework A real or conceptual structure intended to serve as a support or guide for the
building of something that expands the structure into something useful.
Guideline A suggested way of compliance when doing something. It is visible to those using
or supporting the use of a particular service but there are no sanctions if not
followed.
Guideline for Intended to present to the eHealth Network’s members a clear guideline with the
Adoption intention for it to be adopted and optionally implemented by the EU MS at
national level in the next step.
National The healthcare IT infrastructure, which manages patient and HP/HCP1
Infrastructure identification and health care records in MS1
NCP National Contact Point as referred to in Article 6 of the 2011/24/EU Directive
NCPeH National Contact Point for eHealth, which may act as an organisational and
technical gateway for the provision of eHealth Cross Border Information Services
NCPeH Set of activities aiming to provide evidence of NCPeH compliance with the full
Deployment range of requirements (LOST) established towards CBeHIS provision
NCPeH Process of preparing, deploying and operating a NCPeH
Implementation
NCPeH Operation Set of activities performed by the MS while providing the service to citizens and
health professionals
NCPeH Set of activities aiming to set up an NCPeH
Preparation
Organisational Defines core characteristics, duties and responsibilities of an NCPeH
Framework
PoC Location where an EU citizen may seek healthcare services. It can be a hospital, a
pharmacy or any other point of the healthcare system of Country B.
Requirement Definition of relevant needs (business, functional, non-functional, technical and
technological) for system specification and implementation
1 see Article 3 (f) and (g) of Directive 2011/24/EU
4
Joint Action to support the eHealth Network
LIST OF TABLES
Table 1. NCPeH implementation – Preparation Stage – tools and mechanisms ............................................... 9
LIST OF FIGURES
Figure 1. Alignment of CBeHIS instruments and work in progress ..................................................................... 7
Figure 2. Compliance establishment process ............................................................................................................ 8
5
Joint Action to support the eHealth Network
TABLE OF CONTENTS
1. Executive summary .............................................................................................................................................. 7
2. Introduction .......................................................................................................................................................... 7
2.1. Scope ........................................................................................................................................................... 7
2.2. Objectives ................................................................................................................................................... 8
3. Country Guide for eHealth NCP implementation.......................................................................................... 8
3.1. Baseline approach ...................................................................................................................................... 8
3.2. Elaboration of instruments: a rational and enhanced approach ........................................................ 9
3.2.1. Requirements and Recommendations ....................................................................................... 9
3.2.2. Service Deployment Plan and Preparation Progress Report ...............................................10
4. Further work .......................................................................................................................................................11
References.....................................................................................................................................................................11
6
Joint Action to support the eHealth Network
1. Executive summary
One of the biggest challenges for EU Member States (MS) willing to provide Cross Border
eHealth Information Services (CBeHIS) is the absence of previous experience and mature
knowledge of the practical activities needed to set up a National Contact Point for eHealth
(NCPeH).
Some of the EU MS have already participated in European-wide initiatives that experienced
the provision of CBeHIS. From those experiences, lessons were learnt and knowledge gained.
Based on those informational assets, there is a solid ground to build upon practical
recommendations to support MS designing a localised plan of activities that can guide the MS
from a starting point of willingness through to the successful preparation and deployment of
the NCPeH.
The purpose of this document is to support Member States by providing a set of
recommendations on how to prepare, deploy and operate a NCPeH.
2. Introduction
2.1. Scope
The overall model presented by the Organisational Framework for eHealth NCP (OFW-
NCPeH) foresees several instruments to support the Cross Border eHealth Information
Services (CBeHIS) Preparation, Deployment and Operation.
The following diagram (Fehler! Verweisquelle konnte nicht gefunden werden.) depicts
the overall model proposed by the OFW-NCPeH and how the “Country guide for eHealth
NCP implementation” recommendation fits with this model and interacts with the other
proposed instruments.
7
Joint Action to support the eHealth Network
Figure 1. Alignment of CBeHIS instruments and work in progress2
The “Country Guide for eHealth NCP implementation” recommendation relates to
several aspects of the preparation stage of the NCPeH, but focuses mostly on Semantic and
Technical aspects. With regard to Legal and Organisational principles and requirements, this
document will refer to the:
Multilateral Legal Agreement (MLA) designed by JAseHN task 6.2 that previously acts as
the eHN legal sub-group;
Organisational Framework of eHealth NCP, designed by JAseHN.
As foreseen in OFW-NCPeH, the preparation stage is the first of 3 (three) stages towards
CBeHIS operation. The OFW-NCPeH also proposes that the baseline content for the
“Country Guide for eHealth NCP implementation” should, as far as possible, use key
epSOS outcomes that have been reviewed and fine-tuned by EXPAND, namely:
Requirements and Recommendations checklist;
Sequential implementation activities;
Project Initiation Document (Pilot Plan).
2.2. Objectives
These provide guidance on how MS can implement their NCPeH by using recommended
common instruments:
Requirements and Recommendations for implementing an NCPeH;
2 Source: Improvement of the figure present in the JAseHN D.5.1.1 Organisational Framework for eHealth NCP
8
Joint Action to support the eHealth Network
Service Deployment Plan;
Service Deployment Progress Monitoring.
3. Country Guide for eHealth NCP implementation
3.1. Baseline approach
There are 3 (three) main stages towards CBeHIS operation as foreseen in OFW-NCPeH.
PREPARATION DEPLOYMENT OPERATION
Figure 2. Compliance establishment process3
According to the OFW-NCPeH, the PREPARATION stage is:
(…) where MS design the national deployment plan and perform national preparatory
activities towards the provision of cross border eHealth services;
and also
(…) The goals defined for each stage may be supported by a set of tools and mechanisms
that guide MS towards each stage scope, as well as providing evidence on which the
governing body may take decisions regarding “readiness level” and “quality of service”.
The following table describes the tools suggested by OFW-NCPeH for the preparation stage
and will be described in greater detail in this chapter.
Table 1. NCPeH implementation – Preparation Stage – tools and mechanisms4
DOCUMENT PURPOSE VALUE ADDED
Member State Support the MS to set up and adopt measures Guide the MS in establishing the
Requirements and required for the optimal establishment of the NCPeH
Recommendations NCPeH
[CHECKLIST]
Member State Service Allow the MS to share national visions and Knowledge about MS aims and plans,
Deployment [PLAN] intentions towards CBeHIS provision in a comparable structured way
Member State Preparation Allow the MS to report NCPeH preparation Knowledge about MS status, activities
Progress [REPORT] activities in a structured and sharable way in progress and known issues
3 Source: JAseHN D.5.1.1 Organisational Framework for eHealth NCP
4 Source: JAseHN D.5.1.1 Organisational Framework for eHealth NCP
9
Joint Action to support the eHealth Network
3.2. Elaboration of instruments: a rational and enhanced approach
Building upon the baseline proposed by OFW, the “Country Guide for eHealth NCP
implementation” presents a practical and pragmatic rationale for the elaboration of the instruments
referred to:
Requirements and Recommendations
Service Deployment Plan and Preparation Progress Report
3.2.1. Requirements and Recommendations
Purpose:
Pave the way for countries to acknowledge and understand the requirements and
recommendations in order to be compliant while setting up the NCPeH.
Support countries to set up and adopt measures required for the optimal
establishment of the NCPeH.
Description:
A checklist of requirements and recommendations that MUST (for requirements) and
MAY (for recommendations) be fulfilled to achieve compliance with other countries
while preparing, deploying and operating the NCPeH.
Tools and mechanisms:
Provide a checklist of requirements, classified and categorised in distinct areas:
o Type of requirement:
Required: MUST be fulfilled;
Recommended: SHOULD be fulfilled.
o Thematic area:
A specific requirement may impact several thematic areas, such as:
Technical, Legal, Security and Trust, Semantic, Dissemination
& Training, Organisational, Testing, Operation, Evaluation.
o Service and role:
Each requirement may be relevant for one or both services (PS
and/or eP) as well as being relevant if you provide a service as
Country A or Country B.
o Source:
Each requirement is captured from a specific document (e.g.
guidelines, specifications, OWF, MLA). By identifying the source, the
instrument makes it possible to drill down and study the requirement
and all its implications within a specific context.
o Fulfilled:
10
Joint Action to support the eHealth Network
This section allows the country to state whether or not the
requirements are fulfilled and present observations, namely to point
out evidence for the fulfilment statement.
Value Added:
Guide the MS in establishing the NCPeH by precisely setting requirements and
recommendations to be fulfilled in the several areas of relevance for the NCPeH and
the CBeHIS.
3.2.2. Service Deployment Plan and Preparation Progress Report
Purpose:
Supports the MP in the implementation of the NCPeH and allows the MS to share
national vision and intentions towards CBeHIS provision and to report the NCPeH
preparation activities in a structured and sharable way.
Description:
It describes the rationale for participation in the CBeHIS environment and identifies
the scope and objectives of the MS NCPeH, the key stakeholders and their relations.
It also suggests sequential implementation steps that can be used by the MS to
structure their implementation activities;
This tool combines 2 (two) instruments suggested by the OFW, the “Member State
Service Deployment [PLAN]” and the “Member State Preparation Progress
[REPORT]”.
Tools and mechanisms:
The Service Deployment Plan (SDP) and Preparation Progress Report (PPR) provide the
country with a structured common way to:
Elaborate national Work Breakdown Structure towards CBeHIS provision;
Report on progress of the NCPeH preparation activities.
In addition to these objectives, this tool should also function as a consolidated progress
report to the CEF initiative, by providing evidence of work done and sustaining the funding
requests.
This tool is made up of 2 (two) perspectives:
Executive summary / dashboard – gives an overview of the work progress for each
area, status, trends and highlights to follow the action.
SDP & PPR – presents recommended steps for each thematic area (e.g. Legal,
Organisational, Semantic, Technical, Security, Dissemination, Evaluation) and
recommends a set of sequential implementation tasks for the countries to structure
their activities. It also provides knowledge about country preparation status, progress
and known issues. The data collected will automatically populate the “Executive
summary / dashboard” perspective.
Value Added:
11
Joint Action to support the eHealth Network
Knowledge about country aims, plans and activities, status of progress and known
issues, in a comparable structured way.
4. Further work
Supported by the eHN approval of the rational and enhanced approach that guides the
elaboration of the “Country Guide for eHealth NCP implementation” instruments, there are
joint activities that must be performed to assure the completeness, suitability and usability of
these instruments, namely:
Jointly (JAseHN and eHDSI) work to fine-tune the completeness of the instruments;
Perform localisation exercise, with a set of countries, to evaluate suitability and usability
of instruments;
Hand over the instruments to the eHDSI, for effective usage by January 2017, when
countries’ preparation activities, under the CEF eHDSI, are foreseen to start.
References
This document is based on several reference materials provided by a number of EU eHealth
projects. The following list provides a non-exhaustive indication of the materials considered
up to and including the present version of this document:
epSOS National Pilot Set Up and Deployment Guide (D3.8.2)
epSOS Requirements and Recommendations
epSOS Project Initiation Document (Pilot Plan template).
12
Ref. Ares(2017)3033026 - 16/06/2017
eHealth Network
POLICY PAPER
on
How to Assess Member States Overall Readiness
to Go Live
eHealth Network
The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth. The Joint
Action supporting the eHealth Network (JAseHN) provides scientific and technical support to the
Network.
Adopted by consensus by the eHealth Network, Saint Julian's, Malta, 9 May 2017
2
eHealth Network
-Keep this page free-
3
eHealth Network
LIST OF ABBREVIATIONS
ACRONYM DEFINITION
CBeHIS CROSS-BORDER eHEALTH INFORMAITON SYSTEMS
eHDSI eHEALTH DIGITAL SERVICWE INFRASTRUCTURE
MS MEMBER STATES
NCPeH NATIONAL CONTACT POINT FOR eHEALTH
SP eHDSI SOLUTION PROVIDER
LIST OF FIGURES
Figure 1: The status of each of CBeHIS implementation stages as well as the relation of the overall linked
documents that represent and define the common basis for the overall CBeHIS process including the
documents that relate to each stage ........................................................................................................................... 6
Figure 2: Interdependecies of technical and policy documents with respective responsibilities and
implementation stages .................................................................................................................................................. 7
Figure 3: eHDSI Generic Services default time plan .............................................................................................. 9
4
eHealth Network
TABLE OF CONTENTS
1. Executive Summary ............................................................................................................................................. 6
2. Introduction .......................................................................................................................................................... 6
3. Overview of key documents for assessment of MS Overall Readiness to Go Live ................................. 7
3.1 MS Requirements and Recommendations ................................................................................................ 8
3.2 MS Service Deployment Plan and MS Preparation Progress ................................................................. 8
3.3 MS Service Readiness and MS Service Initial Audit ................................................................................ 8
3.4 MS Overall Readiness Statement ................................................................................................................ 8
3.5 Go Live Recommendation: ......................................................................................................................... 9
4. Policy processes ................................................................................................................................................... 9
4.1 Testing ........................................................................................................................................................... 10
4.2 Auditing ........................................................................................................................................................ 10
4.3 Readiness Stating ......................................................................................................................................... 10
4.3 Approval to Go Live................................................................................................................................... 10
5. Recommendations ............................................................................................................................................. 11
RECOMMENDATION 1 ................................................................................................................................... 11
RECOMMENDATION 2 ................................................................................................................................... 11
6. Annex................................................................................................................................................................... 12
5
eHealth Network
1. Executive Summary
This paper provides an overview of the Policy Papers and Technical Annexes linked to the
“Go Live” process of Cross-border eHealth Information Systems (CBeHIS) implementation for
Member States (MS). It explains the rationale behind the documents jointly provided by JAseHN
(i.e. Policy Papers) and the eHealth Digital Service Infrastructure (eHDSI) Solution Provider (SP)
(i.e. Technical Annexes) for guiding the MS through the process of Going Live.
2. Introduction
Each MS must undergo the CBeHIS implementation stages as foreseen in the Guideline on
an Organisational Framework of National Contact Points for eHealth: Preparation, Deployment
and Operation. During these implementation stages, the MS need to test their services and
conduct an initial audit before Going Live.
Figure 1: The status of each of CBeHIS implementation stages as well as the relation of the
overall linked documents that represent and define the common basis for the overall CBeHIS
process including the documents that relate to each stage
6
eHealth Network
3. Overview of key documents for assessment of MS Overall Readiness
to Go Live
During the CBeHIS implementation, each MS is assessed against criteria listed in the
technical documents provided by the eHDSI Solution Provider. The assessment of the MS’
overall readiness to Go Live is thus supported by following requirements provided in the
documents listed in Figure 2: Yellow boxes contain the overall Policy Papers provided by
JAseHN to the eHN and green boxes contain Technical Annexes mainly provided by the eHDSI
SP1. Both are assigned in each stage of CBeHIS implementation to specific bodies listed in the
blue boxes. The Agreement between National Authorities or National Organisations responsible
for National Contact Points for eHealth on the Criteria required for the participation in Cross
Border eHealth Information Services is a legal requirement that must be followed by each MS
intending to Go Live while the Organizational Framework of eHealth NCP (OFW-NCPeH)
describes the overall process from Preparation to Operation stages of CBeHIS implementation.
Figure 2: Interdependecies of technical and policy documents with respective responsibilities
and implementation stages
1 Recommendation to the eHN in JAseHN D5.6.3 Policy Paper on Assessment and Decision Procedures
under CEF Funding
7
eHealth Network
The Technical Annexes for assessment of MS Overall Readiness to Go Live are described below.
3.1 MS Requirements and Recommendations
Explanation: This document provides all necessary criteria related to the CBeHIS
implementation that shall be followed by each MS intending to join the eHDSI during
Preparation stage.
Source: See Annex 1
3.2 MS Service Deployment Plan and MS Preparation Progress
Explanation: This document describes the individual MS plan for the implementation of
CBeHIS services describing the preparation activities for NCPeH deployment in a structured,
common and comparable way. The MS Service Deployment Plan is an appendix of the eHDSI
NCPeH Deployment Guide, produced and maintained by the eHDSI Solution Provider. The MS
Service Deployment Plan also represents the first deliverable of every country participating in the
eHDSI. The MS Preparation Progress is a follow-up to the MS Service Deployment Plan and is
used for frequent reporting. Whereas the MS Service Deployment Plan is produced only once,
the MS Preparation Progress is produced on a quarterly basis by each MS.
Source: See Annex 2
3.3 MS Service Readiness and MS Service Initial Audit
Explanation: MS Service Readiness and MS Service Initial Audit are parts of the Audit
Framework. The Audit Framework is elaborated and maintained by the eHDSI SP with an
annual release plan in March. The main purpose of the Audit Framework is to provide guidance
to the Auditing Body on how to plan, execute and evaluate the adherence by MS to the
Readiness Criteria.
The MS Service Readiness is represented by the Readiness Checklist which is an
annex of the Audit Framework. The purpose of the Audit Checklist has to
elaborate specific questions for the NCPs, and facilitate understanding of how
controls match between the standard and what the NCPs would need to have in
place regarding internal policies, processes and controls. It is based on the ISO
27002:2013 standard.
The MS Service Initial Audit is represented by the Audit Report Template which is an
annex of the Audit Framework. The Audit Report details the audit findings based on
the implementation level of the Readiness Criteria.
Source:
Audit Framework: See Annex 3
Audit Checklists: See Annex 4
Audit Report Template: See Annex 5
3.4 MS Overall Readiness Statement
8
eHealth Network
Explanation: MS Overall Readiness Statement is a declaration statement by every MS applying
to Go Live. It formally declares that a country is ready to Go Live with the respective services
and shall therefore be signed by an authorized person representing the MS. A template to be
filled-in by every country is provided by eHDSI Owner.
Source: See Annex 6
3.5 Go Live Recommendation
Explanation: The Go Live Recommendation is a report being the main basis for the eHN
members to make the Go Live decision for an applicant MS. The Go Live Recommendation is
based on the Go Live Recommendation Report Template, which will be elaborated by
eHMSEG2. The Go Live Recommendation Report lists the main findings of the Test Report,
Audit Report and includes a Risk Assessment for each MS applying to Go Live.
Source: See Annex 7
4. Policy processes
In order to implement CBeHIS, there is a need for monitoring MS progress through
different implementation stages. Therefore, a common timeline was established in order to
ensure alignment and compliance to the above listed document before (and after) Going Live.
The overall process of CBeHIS implementation, from the Preparation stage to the Operation
stage, is depicted in Figure 3.
Figure 3: eHDSI Generic Services default time plan
The steps as indicated in figure 3 are further described below:
2 eHOMB will support eHMSEG in this process via their secretariat.
9
eHealth Network
4.1 Testing
MS’s activities for testing the deployed services. Testing events are organized every year during
the CBeHIS implementation under CEF eHDSI and follow the eHDSI SP Test Framework.
Three major testing events (or more if needed) are planned and result in a report to eHMSEG:
Boot Camp(s) (January): preparatory event to coach and guide the MS regarding the
adoption of specifications, reference implementation and testing mechanisms, organized
by MS or the European Commission;
Connect-a-thon (April): conformance-testing event organised by IHE;
Project-a-thon (September): conformance-testing event organised by the eHDSI SP.
After the testing, the test report is produced and sent to eHMSEG.
Source: See Annex 8
4.2 Auditing
The auditing activity performed by the Auditing Body objectively evaluates the adherence of
NCPeH to legal, organizational, semantic and technical criteria as defined by the eHDSI SP
Audit Framework. A MS can apply for the auditing procedure whenever it wishes within the
foreseen timeframe based on Figure 3. After the auditing, the Auditing Body submits the
Member States Audit Report to eHMSEG.
Source: See Annex 3
4.3 Readiness Stating
Each individual MS activity to summarise all evidence in a common format (i.e. MS Overall
Readiness Statement) which is provided to eHMSEG for review. Readiness Stating is best done
after successfully going through the Testing and Auditing procedures. Upon a successful
Readiness Stating and after reviewing the Audit and Test reports (i.e. combined), eHMSEG3
prepares a report (i.e. Recommendation Report to Go Live) for the eHN in order to support the
application of the MS for the Go Live decision.
Source: See Annex 6 & 7
4.3 Approval to Go Live
The eHN’s decision to permit an MS to move into the Operation stage of CBeHIS
implementation, i.e. to Go Live which is based on the Recommendation Report to Go Live
produced by eHMSEG4 after reviewing the reports from Auditing, Testing and Readiness
Stating. After this approval is made, a MS is permitted to share cross-border information with
other MS that are in Operation stage.
Source: eHN Meeting documentation
3 eHOMB will support eHMSEG in this process via thier secretariat
4 Id.
10
eHealth Network
5. Recommendations
The eHN members are asked to agree with the recommendations listed below:
RECOMMENDATION 1
The eHN agrees to use the Policy Papers and Technical documents (i.e. Technical
Annexes) for the intended purpose of guiding the Member States through the
Preparation and Deployment stages of CBeHIS implementation including Assessment
and Decision phase, as described in Chapter 3 of this document.
NOTE: FUTURE RELEASES OF THESE TECHNICAL DOCUMENTS
NEED TO BE ADOPTED BY eHMSEG IN A TRANSPARENT MEMBER
STATE REVIEW PROCESS
RECOMMENDATION 2
The eHN agrees with the policy processes, as described in Chapter 4 of this document.
11
eHealth Network
6. Annex
Overview table of Technical Annexes
Official
Annex Drafted Review
Document Name Source
Number by Process by
MS
1 MS Requirements LINK eHDSI No
and Owner
Recommendations
2 MS Service eHMSEG eHMSEG
Deployment Plan MS
Depl-Plan_Template
and MS _to-be-filled-in_v8.xlsx (18.04.2017)
Preparation
Progress
3 Audit Framework LINK eHDSI eHMSEG
Solution MS
Provider (04.04.2017)
4 Readiness Criteria eHDSI eHMSEG
Checklist Solution MS
eHealth-Readiness (04.04.2017)
Criteria Checklist_v1.00.xls Provider
5 Audit Report LINK eHDSI eHMSEG
Template Solution MS
Provider (04.04.2017)
6 MS Overall (not available yet) eHDSI No
Readiness Owner
Statement
7 Go Live JAseHN D5.6.3, JAseHN, JAseHN
Recommendation Annex T5.6 sPSC MS
(11.04.2017)
8 Test Framework LINK eHDSI No
Solution
Provider
12
Ref. Ares(2017)3033026 - 16/06/2017
eHealth Network
POLICY PAPER
on
assessment and decision procedures under CEF funding
Joint Action to support the eHealth Network
The eHealth Network is a voluntary network, set up under article 14 of Directive 2011/24/EU.
It provides a platform of Member States' competent authorities dealing with eHealth. The Joint
Action supporting the eHealth Network (JAseHN) provides scientific and technical support to the
Network.
Adopted by consensus by the eHealth Network, Brussels, 21 November 2016
2
Joint Action to support the eHealth Network
-Keep this page free-
3
Joint Action to support the eHealth Network
TABLE OF CONTENTS
1. Executive summary ........................................................................................................... 5
2. Introduction ....................................................................................................................... 5
3. Status of previous deliverables ......................................................................................... 6
4. Objective ............................................................................................................................ 6
5. Proposed processes and responsibilities .......................................................................... 7
6. Recommendations .............................................................................................................. 14
Annex I: ................................................................................................................................... 16
4
Joint Action to support the eHealth Network
1. Executive summary
The purpose of this document is to describe the approval process for a Member State’s (MS)
decision to “go live” with its Cross-Border eHealth Information Services (CBeHIS), specifically
the infrastructure and the operations used to exchange real patient related data, in particular
health data, between its members. It also includes a description of the responsibilities, procedures
and methodology used to create a report upon which the decision making process will be based.
This proposal is to be approved by the eHealth Network (eHN) at its 10th meeting on 21st
November 2016.
2. Introduction
There are three stages that have to be completed by a Member State aiming to participate in
the eHDSI as foreseen in the Guideline on an Organisational Framework of National Contact
Points for eHealth (OFW-NCPeH): Preparation, Deployment and Operation, and several
instruments to support the CBeHIS stages are foreseen. For every stage JAseHN provides or has
already provided supporting documents as described in Figure 1.
Figure 1: Alignment of CBeHIS instruments and work in progress
5
Joint Action to support the eHealth Network
D5.1.2 Country Guide for NCPeH implementation was adopted by eHN at its 9th meeting.
The recommendations given in this Country Guide touch upon several aspects of the preparation
stage for the NCPeH, but their focus is mostly on the semantic and technical aspects. With
regard to the legal requirements for CBeHIS, the process will be based on the Legal Agreement
between National Authorities responsible for National Contact Points for eHealth on the Criteria required for the
participation in Cross-Border eHealth Information Services (LA), whereas the OFW-NCPeH will provide
the basis for the organisational aspects.
D5.6.1 Assess Member States’ overall readiness is a document which describes a process that
responsible parties need to implement in order to establish trust between the Member States and
Service Providers. It provides explanations about which steps must be taken by MS while stating
their readiness and the approval process for taking their CBeHIS online. The document will be
submitted to eHN for adoption in May 2017.
3. Status of previous deliverables
D5.1.2 and D5.6.1 both summarise the need for Member States to fulfil the Preparation and
Deployment phases and describe the implementation strategy for CBeHIS provision. D5.1.2 was
adopted by eHN on a generic level but is still missing the technical annexes (i.e. Member State
Requirements and Recommendations checklist) that are needed by the Member States’ technical
experts when they prepare for CBeHIS implementation. D5.6.1 was not presented to eHN but is
available as a draft without the completed technical annexes, such as checklists, the report
template for the Initial Audit and the Readiness Statement (draft available as Annex I of this
document).
Due to the significant level of technical complexity involved, it has turned out that JAseHN is
not in a position to finalise the above-mentioned technical annexes for both documents. It is
therefore proposed that the finalisation of the technical annexes listed above be handed over to
the eHDSI Solution Provider in close liaison with JAseHN-WP5. Both annexes have to be
approved by eHMSEG; D5.1.2 will be sent as an update for information only and D5.6.1 for
adoption at the 11th eHN meeting in May 2017.
4. Objective
The objective of this document is to focus on the elaboration of the processes, roles and
responsibilities for each stage of CBeHIS development under CEF with a strong focus on the
stage between Deployment and Operation. The reason for this is that the final decision to “go
live” will be taken by eHN between these two stages of CBeHIS development.
The other stages have been described elsewhere (see 3. Status of previous deliverables) and
will not be covered in greater detail in this document. All stages of CBeHIS development under
CEF will be mentioned to some extent. The final decision to permit a MS to “go live” is based
upon the processes in the Preparation and Deployment stages.
As such, this document aims to provide eHN members with a summary report
(Recommendation Policy Report Template) of all the necessary preconditions presented to each
MS and their fulfilment status. This report will provide decision-making support to eHN when it
makes the decision to permit a MS to go into the Operation stage, i.e. “go live” with its CBeHIS.
6
Joint Action to support the eHealth Network
5. Proposed processes and responsibilities
The following chapter focuses on the processes that describe the stages of CBeHIS
development. As previously stated, the purpose of this document is not to focus on all the stages
of CBeHIS development but to provide information regarding the Assessment and Decision
process performed by eHN. This intermediate stage of CBeHIS takes place between the
Deployment and Operation stages and its purpose is to collect and validate evidence that a MS is
able to go live and produce a summary of all the results collected in previous stages in order to
support the claim of the MS to be permitted to go into the Operation stage.
Figure 2 further outlines the main responsibility in each individual stage and the related
technical documents that need to be delivered when the three stages are completed:
Figure 2: Responsibility and Delivery Map
The whole process of CBeHIS development under CEF begins with the Preparation
stage. During the Preparation stage, a MS relies on the Country Guide for implementation of
eHealth NCP to produce the first CBeHIS deliverables and build up its national infrastructure for
CBeHIS. As a formal result of this stage, a MS is required to submit a series of reports described
in further detail in the OFW-NCPeH (namely: Member State Service Plan, Member State
Requirements and Recommendations, and Member State Preparation Progress). When it has
reached an expected level of readiness, a MS enters the Deployment stage where it performs
specific testing activities.
The Deployment stage marks the second phase of CBeHIS development. During this
stage, the MS gathers evidence on its readiness level, namely by performing the activities
identified in the eHDSI Testing and Audit Frameworks.
The evidence collected throughout this stage is then compiled in the Readiness Statement
(for draft, see Annex I) prepared by the MS, validated by the third party auditing body
(hereinafter referred to as the Auditing Body) and sent to eHMSEG for assessment. Their
7
Joint Action to support the eHealth Network
recommendation, i.e. the recommendation report to go live, will finally be submitted to eHN for
decision.1
Due to the need for a consolidated approach to decision-making with regard to CBeHIS,
the final decision is made by eHN in accordance with its Rules of Procedure. In order to support
this decision-making process, eHMSEG submits to eHN a filled-in Go Live Recommendation
report that summarises the MS’s overall readiness statement in conjunction with the evidence
produced in the Preparation and Deployment stages that uphold the claim of a MS to “go live”
with its CBeHIS.1
The flow and progress along the different stages proposed will follow a default timescale
agreed for the eHDSI, reinforcing the orchestrated and coordinated approach to decision-
making. The following figure and table describe the default timescale for the full process to
occur.
Figure 3: Default timescale for a MS under the CBeHIS development cycle
1 eHOMB will support eHMSEG in this process via their Secretariat.
8
Joint Action to support the eHealth Network
The description of the steps foreseen for the default timescale for going live:
STEP DESCRIPTION
Wave X – Go Live The commonly agreed date for a MS to go live (services available for
public use) with CBeHIS, depending on the wave chosen:
Wave 1 – February 2018
Wave 2 – February 2019
Wave 3 – February 2020
National Preparation MS’s specific activities towards reaching the CBeHIS readiness levels
needed to go live. A 12 month period is recommended to prepare the
NCPeH.
TESTING2 MS’s activities for testing the services provided by the NCPeH. Three
events are foreseen:
Boot Camp (January): ramp up event to coach and guide the
MS regarding the adoption of specifications, reference
implementation and testing mechanisms;
Connect-a-thon (April): conformance testing event organised
by a third party;
Project-a-thon (September/October): conformance testing
event organised by the EC.
These events should, if possible, occur every year during the CEF
eHealth DSI.
AUDITING Audit performed by the Auditing Body of each MS’s NCPeH, ending
with the finalisation and validation of the Readiness Statement
produced by the MS
Readiness Stating MS’s activity to summarise all the gathered evidence in a common
format, which will then be verified by the Auditing Body and
submitted to eHMSEG for assessment
Elaborate Go Live eHMSEG activity3 to prepare Go Live Recommendation, including
Recommendation any specific instructions to the MS to improve the NCP
implementation
Approval to Go Live eHN decision regarding the "Recommendation Report to Go Live"
received
Operation MS’s activities, once eHN’s decision has been made, towards the
Deployment operational environment in which services will be made publicly
available
Table 1: Description of the steps for every wave
All the stages that the MS goes through before the Operation stage (i.e. final approval for
CBeHIS to “go live” by eHN) are set out in detail below.
2 Information according to the eHDSI Testing Framework. This document is not yet available but the information
was obtained through close collaboration with the eHDSI Solution Provider responsible for its preparation.
3 eHOMB will support eHMSEG in this process via their Secretariat.
9
Joint Action to support the eHealth Network
5.1 Stage I: Preparation
Figure 4: From the Preparation to the Deployment stage
Tools and mechanisms (as defined by OFW-NCPeH) - Figure 3:
The documents included in the OFW-NCPeH (Chapter 4.2 Process) that guide Member
States and provide evidence of successful CBeHIS implementation during the Preparation stage
are:
Member State Service Plan (PLAN)
Member State Requirements and Recommendations (CHECKLIST)
Member State Preparation Progress (REPORT)
Rationale:
According to the OFW-NCPeH (Chapter 4.2 Process), Member States design the national
deployment plan and perform national preparatory activities towards the provision of cross-
border eHealth activities. The purpose of these three documents is to describe the Preparation
stage completed by the MS that will lead into the Deployment stage.
Process:
The Member State Preparation Progress Report, which includes the Member State Service
Plan and the Member State Requirements and Recommendations, ensures that a country is
permitted to enter the Deployment stage, during which further evidence is gathered in order for
the Member State to “go live”.4
4
Member State Service Plan and Member State Preparation Progress are to be provided in the JAseHN
D5.1.2. Checklist of Requirements and Recommendations, which will be finalised jointly by the eHDSI solution
provider and JAseHN WP5.
10
Joint Action to support the eHealth Network
5.2 Stage II: Deployment
Figure 5: From Deployment to the Assessment and Decision stage
Tools and mechanisms (as defined by the OFW-NCPeH) - Figure 4:
The documents included in the OFW-NCPeH (Chapter 4.2 Process) that guide Member
States and provide evidence of successful CBeHIS implementation during the Deployment stage
are:
Member State Service Readiness (CHECKLIST)
Member State Services Initial Audit (REPORTS)
MS Overall Readiness Statement (CHECKLIST)
Rationale:
The purpose of these three documents is to support the Member States in setting up and
adopting the measures required for operational establishment of the NCPeH. The Member State
Service Readiness Checklist, Member State Services Initial Audit Reports and MS Overall
Readiness Statement (validated by the Auditing Body) provide evidence that supports the claim
of each Member State to move from the Deployment stage and “go live”.
Process:
During the Deployment stage, an individual Member State tests its CBeHIS in a formal
testing event. The purpose of this is to test the services in a scrutinised and independently
operated context. The resulting report serves as evidence of technical readiness for CBeHIS
implementation.
The Auditing Body performs this test and submits the MS Services Audit Report to the MS.
11
Joint Action to support the eHealth Network
After these two steps have been performed and documents produced, the third step is for the
MS to produce the Overall Readiness Statement (for draft, see Annex I). This statement should
be validated by the Auditing Body and then provided to eHMSEG, where it should be assessed
before the Member State can proceed towards eHN with a Go Live Recommendation Report.
5.3 Assessment and Decision procedure
Figure 6: Assessment and Decision procedure
Tools and mechanisms – Figure 5:
The document that eHN will need for the approval and decision that a Member State is ready
to “go live” is the:
Recommendation to Go Live (REPORT)
Rationale:
Between the Deployment and Operation stages, there needs to be an assessment and decision
phase during which a Member State’s readiness will be evaluated by eHN. All available tools and
mechanisms produced during previous stages will provide the basis for eHMSEG5 to deliver the
Recommendation Report to Go Live, which will be submitted to eHN in order for the Member
State’s request to “go live” to be approved.
This report will be based on the MS Overall Readiness Statement, which provides a
measurable set of criteria and a ranking methodology as a decision-making tool.
Process:
The documents from earlier stages (Preparation and Deployment) provide the basis for a MS
to produce the Overall Readiness Statement, which summarises the conclusions of all the
aforementioned documents and expresses the final readiness to “go live”. Following its validation
by the Auditing Body, the Member State submits the Overall Readiness Statement together with
other documents to eHMSEG. eHMSEG then assesses the submitted documents and produces
the Recommendation Report to Go Live8. This report will be submitted to eHN for final
approval, upon which a Member State is allowed to “go live” and move into the Operation stage
5 eHOMB will support eHMSEG in this process via their Secretariat.
12
Joint Action to support the eHealth Network
of CBeHIS development. The MS Overall Readiness Statement is attached as a draft document in
Annex I of this document for information. The final version of this statement will become part
of the JAseHN deliverable 5.6.1 Assess Member States’ overall readiness, which is to be
submitted for adoption at the 11th eHN meeting in May 2017.
The approval to “go live” is given by eHN in accordance with its Rules of Procedure, as is
the case with any other eHN decision. eHN bases its decision upon the Recommendation Report
to Go Live, which contains the results elaborated in the submitted MS Overall Readiness
Statement. The statement contains the summary results describing the achieved level of
performance of deployed generic services and the overall readiness of each MS to “go live”.
STEP STAGE DESCRIPTION
Set up the NCPeH Preparation MS’s specific activities towards reaching the CBeHIS
readiness levels necessary to go live
Perform Testing Deployment MS’s activities for testing the services provided by the
NCPeH
Elaborate Readiness Deployment MS’s activity to summarise all the gathered readiness
Statement evidence, in a common format, and state its readiness
[Readiness Criteria] to go live. This will be validated by the Auditing
Body.
Perform Audit Deployment MS NCPeH audit performed by a third party
Elaborate Go Live Assessment & eHMSEG6 activity to prepare Go Live
Recommendation Decision Recommendations according to the Readiness
(eHN template) Statement provided by the Member State and
validated by the Auditing Body
MS Go Live Assessment & eHN’s approval of the Go Live Recommendations
Approval Decision
Operation Deployment Operation MS deploy the NCPeH in the operational
environment in which services will be made publicly
available
Table 2: Description of the steps foreseen in the Go Live assessment decision
6 eHOMB will support eHMSEG in this process via their Secretariat.
13
Joint Action to support the eHealth Network
6. Recommendations
eHN members are asked to:
Agree with the recommendations listed below:
Recommendation 1
eHN agrees with the sequence of interlinkage of the documents as illustrated in Figure 1
and Figure 2 of this document.
Clarification:
Because several other documents already exist, particularly the Legal Agreement that
contains cross-references to all the documents listed in Figure 1 and Figure 2, a decision
by eHN is needed in order to reach a final basis for future reference.
Recommendation 2
eHN agrees with the proposed processes, including the responsibilities as described in
Table 2
Clarification:
It turns out that there is a lack of clarification relating to the needed and necessary
procedures, processes, methodology, functions and responsibilities. This document
provides the process for obtaining the correct information and the information that
needs to be provided to eHN in order to be able to make a decision about a Member
State going live.
Recommendation 3
Future reports linked to the Operation stage that refer to the “Annual report on
operational support to Open NCP usage” will be elaborated by eHMSEG (and not by
JAseHN, as initially planned).
Clarification:
JAseHN has already produced one report that generally refers to the preparatory work
done so far in this context. The future alignment work between the Member States
concerning the coordination of the technical and organisational implementation of the
NCPeH will be done within eHMSEG. Therefore, it is reasonable to appoint eHMSEG
as the responsible body for reporting on operational support to Open NCP usage at
Member State level.
14
Joint Action to support the eHealth Network
Recommendation 4
The Member States agree to commit themselves to process, at their 11th meeting,
the technical annexes to
o D5.1.2 Country Guide for NCPeH implementation for information;
o D5.6.1 Assess Member States’ overall readiness for adoption;
o The technical annexes will be finalised and completed by the eHDSI solution
provider in close liaison with JAseHN-WP5 by the end of February 2017, after
which they will be reviewed by eHMSEG.
The OFW-NCPeH, which has already been adopted, needs some fine-tuning in
terms of consistency, which will be done by JAseHN, before its adoption by eHN
at its 11th meeting in May 2017.
Clarification:
The OFW-NCPeH, which serves as one of the main basic documents, provides clear
references to D5.1.2 Country Guide for NCPeH implementation, including the technical
annexes. These aim to support the Member States in setting up and adopting the
measures required for optimal establishment of the NCPeH and are needed by the
Member States to enable them to understand the requirements and recommendations for
compliance with other Member States’ NCPeH.
15
Annex I:
Member State Overall Readiness Statement
(Template)
Country name:
Service: o ePrescription A
o ePrescription B
o Patient Summary A
o Patient Summary B
Range of coverage of o Local
o Regional
the service: o National
eHealth Network
Contact person details:
Name:
Organisation:
Official address:
Email:
Telephone number: +‘country code’ ‘area code’ ‘number’
Fax number: +‘country code’ ‘area code’ ‘number’
List of annexes:
Name of document: Abbreviation:
Member State Service Plan ISO Alpha-2 Country Code-SP7
Member State Requirements and ISO Alpha-2 Country Code-RR
Recommendations
Member State Preparation Progress ISO Alpha-2 Country Code-PP
Member State Service Readiness ISO Alpha-2 Country Code-SR
Member State Services Initial Audit ISO Alpha-2 Country Code-SIA
8
(…)
7
The ISO alpha-2 country codes are part of ISO 3166, which is the International Standard for country codes
and codes for their subdivisions. The country codes represented as a two-letter code are called ISO alpha-2
country codes, e.g. AT, BE, HR, DE, FR, etc. (http://www.iso.org/iso/home/standards/country_codes.htm)
The second part of the abbreviations are the abbreviations of the document referred to (SP = Member State
Service Plan, RR = Member State Requirements and Recommendations)
8
Additional documents may be added if necessary but it would be useful for the same abbreviations as above
to be used.
17
eHealth Network
Services in operation stage9
Service YES NO
Patient Summary - Country A
Patient Summary - Country B
ePrescription - Country A
ePrescription - Country B
This statement about a member state’s overall readiness to provide CBeHIS is envisioned to be
the baseline for producing the Recommendation Report to Go Live. Information is about a
Member State’s (MS) readiness to go live and move into the Operations stage of cross-border
eHealth services (CBeHIS) development. It is divided into legal, organisational, technical and
semantic preparedness in accordance with the European Interoperability Framework.
The rankings used in this template are:
• Critically deficient — suggests a serious inability to comply with the Approval Criteria.
• Weak — unable to comply entirely with Approval Criteria.
• Satisfactory — Approval Criteria are complied with in a satisfactory manner, but there is
some room for improvement as only some criteria have been met.
• Good — Approval Criteria are complied with and most criteria have been met.
Final considerations:
The purpose of this template is to allow the Member State to make a final statement that it is
able to provide the relevant service. This statement is submitted to eHMSEG, which may
recommend to eHN that the MS be allowed to go live and provides eHN with the final
document upon which it can give its approval. As such, the statement should be based on other
documents that support the claim of each MS for CBeHIS operational readiness.
The template is filled in by the Member State and provides a summary of the results described in
documents created in the Member State during the preparation phase and the Initial Audit and
conformance testing event. The filled-in template is then validated by the Auditing Body, after
which it will become the basis for the Recommendation Report produced by eHMSEG10 for
eHN to make a final decision on the MS’s readiness to “go live”. The template itself is not a
substitute for a deeper involvement and insight into the MS’ CBeHIS operational preparedness
but serves as an aid in creating a decision-making recommendation report in order to reduce the
risk of permitting a MS to enter CBeHIS operations.
9 This refers to the services already provided in previous waves. Mark with an x where applicable.
10 Same as no. 1
18
eHealth Network
1. LEGAL Interoperability Readiness Criteria
NO. CRITERION READINESS REFERENCE TO THE REMARKS
LEVEL DOCUMENT (abbreviation,
STATEMENT section and/or page)
1.1 MS has made all 1-Yes
necessary legal 2-No
provisions including
those required under
Directive
2011/24/EU for
CBeHIS operation,
guaranteeing this
through the signature
of the Legal
Agreement by its
competent National
Authority responsible
for NCPeH
19
eHealth Network
2. ORGANISATIONAL Interoperability Readiness Criteria
NO. CRITERION READINESS REFERENCE TO THE REMARKS
LEVEL DOCUMENT (abbreviation,
STATEMENT section and/or page)
2.1 A single NCPeH 1-Critically
communication deficient
gateway is responsible 2-Weak
for interaction.
3-Satisfactory
4-Good
2.2 The monitoring 1-Critically
procedures are deficient
established. 2-Weak
3-Satisfactory
4-Good
2.3 National training 1-Critically
materials and activities deficient
are provided to 2-Weak
support CBeHIS
operation. 3-Satisfactory
4-Good
2.4 Support system is 1-Critically
designed and set up. deficient
2-Weak
3-Satisfactory
4-Good
2.5 Health professionals are 1-Critically
engaged in order to deficient
sustain the service 2-Weak
operation.
3-Satisfactory
4-Good
2.6 Citizens are informed 1-Critically
about CBeHIS deficient
provision. 2-Weak
3-Satisfactory
4-Good
2.7 The responsible data 1-Critically
controller and data deficient
processor in 2-Weak
accordance with the
provisions of 3-Satisfactory
Directive 95/46 EC 4-Good
20
eHealth Network
are identified.
2.8 Member State is able 1-Yes
to provide figures on 2-No
the usage of the cross-
border Patient 3-N/A11
Summary by its own
patients (acting as
Country A) and/or
foreign patients
(acting as Country B).
2.9 Member State is able 1-Yes
to provide figures on 2-No
dispensed cross-
border ePrescriptions 3-N/A12
to its own patients
(acting as Country A)
and/or foreign
patients (acting as
Country B).
2.10 Member State is able 1-Critically
to design, set up and deficient
implement an 2-Weak
evaluation strategy to
measure national usage 3-Satisfactory
and impact of cross- 4-Good
border eHealth
service(s) provision.
2.11 An incident management 1-Critically
solution to support deficient
health professionals, 2-Weak
healthcare providers
and citizens is 3-Satisfactory
established and 4-Good
maintained.
2.12 An appropriate audit 1-Critically
trail system is deficient
established (allowing 2-Weak
authorised official
bodies to duly inspect 3-Satisfactory
the data collected, 4-Good
processed, translated
and transmitted).
11 Member State applies for ePrescription only.
12 Member State applies for Patient Summary only.
21
eHealth Network
3. TECHNICAL Interoperability Readiness Criteria
NO. CRITERION READINESS REFERENCE TO THE REMARKS
LEVEL DOCUMENT (abbreviation,
STATEMENT section and/or page)
3.1 Member State is able 1-Critically
to connect the NCPeH deficient
technical gateway to the 2-Weak
national infrastructure.
3-Satisfactory
4-Good
3.2 Appropriate security and 1-Critically
data protection systems deficient
to conform to 2-Weak
CBeHIS requirements
are established. 3-Satisfactory
4-Good
3.3 Results of Connect-a- 1-Critically
thon testing event are deficient
available and MS is 2-Weak
able to perform
scrutiny and peer-to- 3-Satisfactory
peer tests, supervised 4-Good
by external entity.
22
eHealth Network
4. SEMANTIC Interoperability Readiness Criteria
NO. CRITERION READINESS REFERENCE TO THE REMARKS
LEVEL DOCUMENT (abbreviation,
STATEMENT section and/or page)
4.1 Member State has the 1-Yes
current versions of the 2-No
Master Translation
Catalogue (MTC) and
the national part of the
Master ValueSet
Catalogue (MVC), and
keeps them updated
and maintained to the
latest version.
4.2 There is a designated 1-Critically
national competent entity deficient
that is responsible for 2-Weak
the accuracy and
integrity of the 3-Satisfactory
semantic 4-Good
transformation (e.g.
translation and
mapping).
4.3 National versions used 1-Critically
in the semantic deficient
transformation of the 2-Weak
controlled
vocabularies are 3-Satisfactory
maintained. 4-Good
23
eHealth Network
5. OVERALL Interoperability Readiness Criteria
NO. CRITERION READINESS REFERENCE TO THE REMARKS
LEVEL DOCUMENT (abbreviation,
STATEMENT section and/or page)
5.1 Member State adheres 1-Critically
to and cooperates in deficient
accordance with 2-Weak
the“Governance model for
the eHealth Digital 3-Satisfactory
Service Infrastructure 4-Good
during the CEF funding”,
and will continue to do
so.
5.2 MS’s competent 1-Yes
national authority 2-No
responsible for
NCPeH has signed the
Legal Agreement (LA).
5.3 Member State has 1-Critically
complied with the deficient
“Organisational 2-Weak
Framework of eHealth
NCP (OFW-NCPeH)”. 3-Satisfactory
4-Good
5.4 MS has produced a 1-Critically
service compliant with deficient
eHN’s “Restructured 2-Weak
Guidelines for cross-border
exchange of patient 3-Satisfactory
summaries and 4-Good
ePrescriptions”.
24
eHealth Network
General remarks (further improvement plans, overall picture, etc.)
25
My Health @ EU
eHealth Digital Service Infrastructure
Electronic cross-border health services in the EU
eHDSI Wave 3 Formal PPT
ESTONIA (EE) NCPeH
Outcomes Summary Report
Document Control Page
Settings Value
Document Title: EE NCPeH Outcomes Summary Report
Project Title: eHealth DSI
Document Authors: eHDSI Solution Provider
Doc. Version: State of Play as of 27th of May, 2021
Status and concerned services: Wave 3 Formal PPT
Patient Summary A (PS-A)
Patient Summary B (PS-B)
Sensitivity: Restricted to eHMSEG, eHDSI Owner, eHDSI Solution Provider
Date: 27/05/2021
Link to the source Confluence page: https://ec.europa.eu/cefdigital/wiki/x/swAHBw
1
Table of Contents
1. Services under Preparation to GoLive (Production Environment Testing sessions) (Wave 3) ... 3
2. Coverage Completed during last Acceptance Test Event (Wave 3 Formal & Upgrade PPT) ...... 3
3. Outstanding findings ................................................................................................................... 4
4. Closed Findings, Observations, Production Testing Sessions ..................................................... 5
Legend:
PPT - Pre-production Formal / Upgrade Testing
PET - Production Environment Testing
Last updated: May 27, 2021
2
1. Services under Preparation to GoLive (Production Environment Testing
sessions) (Wave 3)
ID Partners in the Production Link to the Verification by the eDHSI SP. Planned Date of GoLive
Environment Testing Session Session page for the services
Findings / Observations during
the session for EE.
1.
2. Coverage Completed during last Acceptance Test Event (Wave 3 Formal &
Upgrade PPT)
Service Available partners Conformance Tests Required Conformance tests
performed - WF with with partners
partners
Conformance testing
PS-A (Conformance - min 3 1. HR, CY, CZ, EL, FR, LU, MT, PT, ES 1. None 1. No
partners) 2. Extended Week June-2020: CZ, HR, LU 2. CZ, HR, LU 2. Only for WF, missing 2
partners for
eHDSI_Auhtorization Test
PS-B (Conformance - min 3 1. HR, CY, CZ, E, IE, LU, MT, PT, ES 1. None 1. No
partners) 2. Extended Week June-2020: CZ, HR, LU 2. CZ, HR, LU 2. Only for WF, missing 1
partner for
eHDSI_Auhtorization Test
eP-A (Conformance - min 3 HR, CY, CZ, EL, FI, PL, PT, SE FI, HR, PL, PT, SE Yes
partners)
eP-B (Conformance - min 3 HR, CY, CZ, EL, FI, IE, PL, PT, SE FI, HR, PT, SE Yes
partners)
Service Available partners Evaluations submitted Required evaluations submitted
Functional testing
PS-A (Functional - own PS 1. HR, CY, CZ, EL, FR, LU, MT, PT, ES 1. LU, PT Yes
docs evaluated by partners) 2. Extended Week June-2020: HR, CY, CZ, 2. HR
LU, PT
PS-B (Functional - PS docs 1. HR, CY, CZ, EL, IE, LU, MT, PT, ES 1. None Yes
from partners evaluated) 2. Extended Week June-2020: HR, CY, CZ, 2. CY, CZ, IE
IE, LU, PT
3
Service Available partners Conformance Tests Required Conformance tests
performed - WF with with partners
partners
eP-A (Functional - own eP 1. HR, CY, CZ, EL, FI, PL, PT, SE 1. CZ, SE Yes
docs evaluated by partners) 2. Extended Week June-2020: HR, CY, CZ, 2. CZ, FI
FI, PT
eP-B (Functional - eP docs 1. HR, CY, CZ, EL, FI, IE, PL, PT, SE 1. None Yes
from partners evaluated) 2. Extended Week June-2020: HR, CY, CZ, 2. HR, FI, PT
FI, IE, PT
eP-A (Functional - eD docs 1. HR, CY, CZ, EL, FI, PL, PT, SE 1. None Yes
from partners evaluated) 2. Extended Week June-2020: HR, CY, CZ, 2. CZ, FI, PT
FI, PT
eP-B (Functional - own eD 1. HR, CY, CZ, EL, FI, IE, PL, PT, SE 1. CY, PL, SE Yes
docs evaluated by partners) 2. Extended Week June-2020: HR, CY, CZ, 2. HR
FI, IE, PT
3. Outstanding findings
ID Service & Finding Comments and/or Action Plan by the Comments by the eHDSI Solution Provider
Test Event NCPeH
f-4 16 Mar Agent causing the According to ArtDecor its R 1..1, which in In the PS Functional Requirements, the
2020 allergic reaction not turn means that we are allowed to use agent causing the allergic reaction is
coded nullFlavor="NI". Would it be better to considered as 'basic', that's the reason why
PPT W3,
remove the agent overall from Estonian when missing, it's considered a finding.
PS-A,
PS?
Functional Solution Provider on 23 Mar 2021: this
29 Mar 2021: situation can be considered as having a
medium impact, given that in the original
Allergy data was initially planned to be
narrative part of the Section and in the
nationally available in 2020, but due to
Level 1 PDF the information about the
covid developments this has been
agent causing the allergic reaction is
postponed to 2022.
provided (in Estonian). A Health
Professional attending a patient with an
allergy would need to use a translation tool
or, when possible and feasible (using a
language understood by both), ask the
patient or relative about that information.
4
ID Service & Finding Comments and/or Action Plan by the Comments by the eHDSI Solution Provider
Test Event NCPeH
f-6 16 Mar Medication entries 29 Mar 2021: Solution Provider on 23 Mar 2021: this
2020 are repeated three situation can be considered as having a
Depending on the situation the doctors will
times. The situation medium impact. Health professional can
PPT W3, still prescribe the prescriptions as they
happens as well in the be confused especially when the number
PS-A, have so far, so for the repeated
narrative part and in of distinct medications is high (mentioned
Functional prescriptions it is expected to see 3
the Level 1 PDF for other PS test data that contained more
prescriptions with the same data, but
repetitions) and the start date is not
different prescription number. Statistically,
indicated.
about half of the prescriptions prescribed
in Estonia are repeated prescriptions.
f-8 16 Mar Onset date of 06 May 2021: Date of onset of medication is considered a
2020 medication not 'basic' element in the PS Functional
We discussed the topic internally and
present Requirements.
PPT W3, eventually HWISC feels that there is no
PS-A, right way to present the data (time, when Solution Provider on 23 Mar 2021: this
Functional the prescription was issued isn't really situation can be considered as having a
correct and the time it was dispensed is low impact, especially when providing the
also not correct). Since „The agreed data date of onset of the health problem for
elements must be sent by each NCPeH, which the medication is prescribed.
even if there is no content available
Only in some situations it would be more
(exceptional values are allowed)“ we
relevant: e.g. recent prescriptions causing
should be fine, since we are sending the
an adverse reaction, to evaluate a lack of
element itself and using UNK.
efficacy of a treatment.
4. Closed Findings, Observations, Production Testing Sessions
The closed findings, observations and Production Testing sessions can be found at the following
link: https://ec.europa.eu/cefdigital/wiki/x/UIY7Dg
5
Ref. Ares(2021)1363954 - 19/02/2021
EUROPEAN COMMISSION
DIRECTORATE-GENERAL FOR HEALTH AND FOOD SAFETY
Health and food audits and analysis
DG(SANTE) 2020-7091
FINAL REPORT OF AN AUDIT
CARRIED OUT OF
ESTONIA
FROM 4 JUNE 2020 TO 16 OCTOBER 2020
IN ORDER TO
ASSESS THE NATIONAL CONTACT POINT FOR eHEALTH'S READINESS
FOR JOINING THE CROSS BORDER
eHEALTH INFORMATION SERVICES NETWORK FOR THE NEW SERVICES
PATIENT SUMMARY COUNTRY A AND PATIENT SUMMARY COUNTRY B
Executive Summary
This audit was undertaken at the request of the Health and Welfare Information System Centre
(TEHIK), which operates the Estonian National Contact Point for eHealth (NCPeH). The objective
of the audit was to assess the readiness of this NCPeH to join the Cross-Border eHealth Information
Services Network for the new services Patient Summary country A (PS-A) and Patient Summary
country B (PS-B). Due to the restrictions imposed by the COVID-19 pandemic, this audit took place
remotely by exchange of documentation and video meetings over several sessions from 4 June to 16
October 2020.
Overall, the report concluded that although the NCPeH organisation is well advanced in complying
with the requirements, work remains to be done in a number of areas. These refer to controllers’
and processors’ obligations, patients’ rights and freedoms, information security management
system and service operations, where non-compliances with the new services requirements create
some risks to the confidentiality and availability of patient data.
In addition, there were deficiencies in the monitoring of service availability and response time,
which may have an impact on availability. There were no findings indicating that integrity would be
at risk.
The report contains recommendations to the Estonian NCPeH aimed at rectifying the shortcomings
identified.
I
Table of Contents
1 Introduction ....................................................................................................................................1
2 Objectives and scope......................................................................................................................1
3 Audit criteria ..................................................................................................................................1
4 Background ....................................................................................................................................2
5 Findings and conclusions ...............................................................................................................2
5.1 Controllers’ and processors’ obligations .................................................................................2
5.2 Patients’ rights and freedoms ..................................................................................................5
5.3 Information security management system...............................................................................5
5.4 Service Operations.................................................................................................................10
5.5 Quality of health data ............................................................................................................12
6 Overall Conclusions .....................................................................................................................12
7 Closing Meeting ...........................................................................................................................12
8 Recommendations ........................................................................................................................13
II
ABBREVIATIONS AND DEFINITIONS USED IN THIS REPORT
Abbreviation Explanation
CBeHIS Cross Border eHealth Information System
DPIA Data Protection Impact Assessment
DSI Digital Service Infrastructure
eHDSI eHealth Digital Service Infrastructure
eHealth The use of information and communication technologies for health
eHMSEG eHealth Digital Service Infrastructure Member State Expert Group
EU European Union
GDPR General Data Protection Regulation
NCPeH National Contact Point for eHealth
PIN Patient Information Notice
PS-A Patient Summary country A (country of affiliation)
PS-B Patient Summary country B (country of treatment)
Recommendation Recommendation is an advice to the NCPeH to address a finding or
a group of findings
TEHIK Health and Welfare Information Systems Centre
TLS Transport Layer Security
III
1 INTRODUCTION
The audit was undertaken at the request of the Health and Welfare Information System
Centre (TEHIK), which operates the Estonian National Contact Point for eHealth
(NCPeH), eHealth meaning the use of information and communication technologies for
health. Due to the restrictions imposed by the COVID-19 pandemic, this audit took place
remotely by exchange of documentation and video meetings over several sessions from 4
June to 16 October 2020.
The audit team comprised two auditors from the European Commission. The opening
meeting took place on 4 June 2020 with representatives from the NCPeH. At this meeting
the audit team confirmed the objectives of the audit. The schedule of the audit was
agreed in consultation with the NCPeH, which also agreed to carry out the audit in
English.
2 OBJECTIVES AND SCOPE
The objectives and scope of the audit were to assess the readiness of the NCPeH for
joining the Cross Border eHealth Information System (CBeHIS) Network for the new
services Patient Summary country A (PS-A) and Patient Summary country B (PS-B). PS-
A refers to the provision to the health professionals in other Member States of essential
health information regarding patients originating from Estonia (country of affiliation –
country A). PS-B refers to the provision to the health professionals in Estonia of essential
health information regarding patients originating from other Member States (country of
treatment – country B).
The audit team verified the NCPeH compliance with the requirements agreed by the
eHealth Digital Service Infrastructure Member State Expert Group (eHMSEG).
Particular emphasis was given to verifying that appropriate policies and processes are in
place (including activities carried out by sub-contracted parties), are communicated
throughout the organisation and are being implemented in order to preserve the
confidentiality, integrity and availability of patient data.
3 AUDIT CRITERIA
The criteria against which TEHIK was audited are the requirements, as laid down in the
eHealth Digital Service Infrastructure (eHDSI) Audit Framework version 4.0.1 adopted
by the eHMSEG on 16 June 2020. The requirements are business requirements, solution
requirements, specifications (insofar as the NCPeH's conformity with eHDSI
specifications has not been assessed by the eHDSI Testing process) and guidelines
applicable to a service. EU law requirements are included in so far as they stem from the
afore-mentioned elements.
1
Since the readiness criteria checklist (version 1.2.1) approved by the eHMSEG on 12
December 2018 remains compulsory for the NCPeH’s self-assessment before an audit is
requested, where necessary, reference to related readiness criteria will be provided with
the aim of highlighting that a certain requirement might be partially covered under the
umbrella of one or more readiness criteria.
Full legal references are provided in Annex 1. Legal acts quoted in this report refer,
where applicable, to the last amended version.
4 BACKGROUND
TEHIK has already joined the CBeHIS network for the services ePrescription country B
and ePrescription country A. On 9 March 2020, the director of TEHIK submitted a
request for an audit of this organisation for the new services PS-A and PS-B.
TEHIK is an agency under the umbrella of the Ministry of Social Affairs of Estonia, in
which has been delegated the responsibility of acting as the NCPeH for cross-border
health information, following the Estonian Healthcare Services Organization Act of 18
May 2020. TEHIK was founded on 1 January 2017 as a competence centre for
information and communication technologies in the health, social protection and labour
field, consolidating the roles and responsibilities of the former information and
communication technologies department of the Ministry of Social Affairs and the
Estonian eHealth Foundation. The main responsibilities of TEHIK include the
development of information systems, databases and e-services; the maintenance of
services and infrastructure; the provision of information security; and the analysis of data
to support policymaking, reporting, productivity monitoring and supervision.
TEHIK has signed contracts with approximately 1 500 healthcare practitioner
organisations that will grant them access to PS-B service in Estonia. There are
approximately 8 000 healthcare professionals as potential users, of whom 2 000 are
thought to be medical doctors.
5 FINDINGS AND CONCLUSIONS
For the purpose of this audit report, the term finding is used as defined in the eHealth
Audit Framework (version 4.0.1). The conclusions summarise the findings and highlight
their impact.
5.1 CONTROLLERS’ AND PROCESSORS’ OBLIGATIONS
Requirements
This section contains an assessment of compliance with the obligations for controllers
and processors established in the technical specification of the eHDSI. These
specifications relate, notably, to requirements laid down in Regulation (EU) 2016/679 of
2
the European Parliament and of the Council (the General Data Protection Regulation –
GDPR). The detailed applicable requirements that were used in the audit were as follows:
Interoperability Specification v.2.1.0:
o The Purpose and manner of the data processing must be covered by the
patient’s consent regarding all eHealth Digital Service Infrastructure (DSI)
services (section 5.2.1).
o The provisioning of medical data for cross-border medical use cases must
require a wilful and documentable act of agreeing by the patient (section
5.2.1).
o The respective consent must be given in written form and must be signed by
the patient (section 5.2.1).
o A qualified digital signature may be used instead of a wet signature (section
5.2.1).
o A country must assure that patient data is only accessible if a valid patient
consent for data provisioning exists (section 5.2.1)
o This willful act must express the patient’s explicit authorization to allow an
identifiable healthcare professional the execution of defined data access
operations (section 5.3.2).
o This willful act must express the explicit authorization of the patient to
transfer medical data to the formerly identified and specifically documented
destination (section 5.5.1).
o The Patient Consent is the legal precondition for any eHealth DSI
transaction – before any higher eHealth DSI business function may be
activated, a valid patient consent (or legitimate overriding condition) needs
to be in place (Section 5.2.2.).
o The eHealth DSI Patient Consent provisions mandate a two-step consent
principle: one fundamental consent for the patient’s specific approval to
participate in eHealth DSI application itself and a specific consent (building
on top of the fundamental consent) for approving specific data exchanges
between a Health practitioner on country B and the patient’s medical data
held in the country of affiliation (country A). The specific wording reads as
follows:
First Patient Consent (Fundamental Consent) in country A allows a
health practitioner to prepare specific data with the intention to make
them available in future to other health care providers in the
framework of eHealth DSI.
Second Patient Consent (Specific Consent) in country B for the
processing of health data in the case of actual treatment in country B
(Section 5.2.2).
Article 35.7 of the GDPR lists the minimum contents of a Data Protection Impact
Assessment and in particular, point (c) requires “an assessment of the risks to the
rights and freedoms of data subjects referred to in paragraph 1.”
Identity Management Specification v.3.0.0:
3
o In some countries where the eHealth DSI record is created specifically for
the purposes of eHealth DSI out of existing stored records, it will be
necessary to obtain patient consent locally in country A for the creation of
the eHealth DSI summary. (Section 3.3.1.2).
o It is agreed in eHealth DSI that explicit consent is necessary, except in an
emergency case. (Section 5.5).
o Consent has to be given at a Point of Care. In the event of a patient seeking
treatment in Country B, the Healthcare Provider will hand over an
information “paper” to the Patient in the language of Country B and in the
language of the patient (Country A). This “paper” will assure that consent is
indeed “informed”. (Section 5.5).
Article 7.1 of GDPR: “Where processing is based on consent, the controller shall
be able to demonstrate that the data subject has consented to processing of his her
personal data”.
Findings
1. Data Protection Impact Assessment (DPIA) contains the elements required in
Article 35.7 (a), (b) and (d) of the GDPR, but it is lacking point (c) (i.e. an
assessment of the risks to the rights and freedoms of data subjects). Patient’s rights
and freedoms are explained in the document (except the right for compensation).
However, an evaluation of the impact of cross-border exchange of patient
summaries on those rights is missing. While assessment of the risks is missing, it is
difficult to demonstrate that the measures envisaged to address those risks (as
required by Article 35.7 point (d)) are indeed addressing the relevant risks. [C.7 –
Critical]
2. Estonian law allows health care professionals to process health records without
explicit consent. The same approach is applied to the cross-border exchange of
patient summaries (i.e. consent for cross-border exchange of health data is implicit
and assumed to be given if a patient seeks medical care in another Member State).
As the eHDSI specifications clearly indicate that consent is the legal basis for lawful
processing in the cross-border context, using the national provision of implicit
consent is not in line with the requirements of Interoperability Specification and
Identity Management Specification. [C.4 and C.14 – Critical]
3. Foreign patients using PS-B service receive a Patient Information Notice (PIN) at
the point of care and the health care provider ticks a box in the user interface,
indicating that the patient has given his/her consent after reading the PIN. Later on,
the controller will not able to demonstrate that the data subject has consented to
processing according to a specific PIN – as required by Article 7.1 of GDPR. [C.14
– Critical]
4
Conclusions on controller’s and processor’s obligations
Without a complete Data Protection Impact Assessment, the controller cannot
demonstrate that risks arising from cross-border exchange of data were assessed and that
risks to all patient’s rights have been mitigated appropriately. Lack of explicit patient
consent (in PS-A service) has, to some extent, an impact on the fairness and transparency
of processing personal data. Consent management should be in line with specific eHDSI
requirements. Inability to demonstrate consent in PS-B service may leave the controller
vulnerable to legal risks if a patient challenges the consent given at the point of care.
5.2 PATIENTS’ RIGHTS AND FREEDOMS
Requirements
This section contains an assessment of compliance with the obligations relating to data
subjects’ (patients’) rights and freedoms. The detailed applicable requirements that were
used in the audit were as follows:
Requirements Catalogue 04.03: “The NCPeHs must inform all data subjects
(national and foreign citizens, staff, external service providers, health professionals
or others) about how and for what purpose their personal and health data are
processed within the eHDSI cross-border services. All data subjects must be
informed about their rights as concerns the protection of their data. This analysis
must consider the GDPR provisions, as well as any applicable national provisions
on data protection. Further details and model of tools that can be used are
described in the ''eHDSI Guidance on Patient Information Notice (PIN)
Implementation'' and ''Model PIN'' documents.”
Findings
4. At the time of the audit, PINs for services PS-A and PS-B were not available as
required by Requirements Catalogue 04.03. [C.14 – Critical]
Conclusions on patients’ rights and freedoms
Patients’ right to transparency and fairness cannot be respected without PINs, which
ensure that the patients provide an informed consent.
5.3 INFORMATION SECURITY MANAGEMENT SYSTEM
Requirements
This section contains an assessment of compliance with the eHDSI requirements relating
to Information Security Management System and specific security requirements for the
new PS-A and PS-B services. The detailed applicable requirements that were used in the
audit were as follows:
5
Requirements Catalogue 09.01: “NCPeHs must ensure the confidentiality of the
services, data and systems provided within eHDSI and implement specific security
and confidentiality policies, procedures and controls.”
Article 24.2 of the GDPR: “Where proportionate in relation to processing
activities, the measures referred to in paragraph 1 shall include the implementation
of appropriate data protection policies by the controller.”
Article 32.1 of the GDPR: “Taking into account the state of the art, the costs of
implementation and the nature, scope, context and purposes of processing as well
as the risk of varying likelihood and severity for the rights and freedoms of natural
persons, the controller and the processor shall implement appropriate technical
and organisational measures to ensure a level of security appropriate to the risk,
including inter alia as appropriate:
(a) the pseudonymisation and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and
resilience of processing systems and services;
…
(d) a process for regularly testing, assessing and evaluating the effectiveness of
technical and organisational measures for ensuring the security of the
processing.”
European Data Protection Board’s Guideline 04/2019, section 16: “The
implemented measures and safeguards should achieve the desired effect in terms of
data protection, and the controller should have documentation of the implemented
technical and organizational measures. To do so, the controller may determine
appropriate key performance indicators (KPI) to demonstrate the effectiveness. A
KPI is a measurable value chosen by the controller that demonstrates how
effectively the controller achieves their data protection objective.”
Clause 5.2 of ISO 27001: “Top management shall establish an information
security policy that: … includes information security objectives (see 6.2) or
provides the framework for setting information security objectives…”
Clause 6.2 of ISO 27011: “The information security objectives shall: …be
measurable (if practicable)”
Cryptographic Algorithms v.3.0.0: “[ECRYPT-CSA-2016] recommendations
define the eHealth DSI minimum requirements on the selection of cryptographic
keys and algorithms.”
ECRYPT-CSA-2016 Section 3.2.6: “Library functions in programming
languages such as random() in the C programming language must be avoided in
cryptographic applications. In general, such functions tend to be based on very
weak generators such as Linear Congruential Generators. Dedicated
cryptographic PRNG implementations are needed.”
ECRYPT-CSA-2016, Section 5.2.1: “Electronic Code Book (ECB) mode [421]
should only be used to encrypt messages with length at most that of the underlying
block size. Keys must be used in a one-time manner, unless the messages are
6
guaranteed to be unique for every encryption, for example via the use of a nonce.
Without such restrictions ECB mode provides few security guarantees.”
ECRYPT-CSA-2016, Section 8.1: “Given these caveats, we recommend the
following key exchange methods for legacy use in TLS as they provide forward
secrecy:
TLS_DHE_DSS_WITH_*,
TLS_DHE_RSA_WITH_*,
TLS_ECDHE_ECDSA_WITH_*,
TLS_ECDHE_RSA_WITH_*,”
ECRYPT-CSA-2016, Section 8.1: “Looking at the record layer protocol (i.e. the
algorithms to encrypt the actual data), we see that only the use of Camellia and
AES, within a mode such as GCM or CCM, are compatible with the
recommendations in earlier chapters. This means at the time of writing we would
only recommend the following cipher suites, for the record layer for future (and
legacy) use within TLS:
*_WITH_Camellia_128_GCM_SHA256,
*_WITH_AES_128_GCM_SHA256,
*_WITH_Camellia_256_GCM_SHA384,
*_WITH_AES_256_GCM_SHA384,
*_WITH_AES_128_CCM,
*_WITH_AES_128_CCM_8,
*_WITH_AES_256_CCM,
*_WITH_AES_256_CCM_8.”
X.509 Certificates Profile, Section 2.3: “All certificates used for eHealth DSI
operations MUST be issued by a trust service provider issuing certificates in line
with the [eIDAS-Regulation1]. All certificates used for eHealth DSI operations
SHOULD be issued in compliance with the [ETSI EN 319 411-1] defined
Normalized Certificate Policy or the [ETSI EN 319 411-1] defined Extended
Validation Certificate Policy for TLS certificates.“
NCPeH Deployment Guide v. 2.0.0, Section 3.3.1: “Certificate Authorities
MUST be registered in the EU Trusted Lists of Certification Service Providers.”
X.509 Certificates Profile, Section 3.1: “Certificates used by eHealth DSI
services SHOULD be valid for a maximum of 2 years.”
Multilateral Agreement, section II.1.1.2 (b): “Contracting Parties using
electronic means of identification that are notified under Regulation (EU) No
910/2014 and applicable to the health domain, shall adhere to this Regulation, its
Implementing Acts and the documents that are referred to in the Annex.”
Multilateral Agreement, Clause II.4.1: “In order to be admitted to participate in
the CBeHIS according to the process defined under Clause III.1.2.1 of this
Agreement, each Contracting Party shall ensure the compliance of its NCPeH with
the principles of data protection by design and by default…”
1 Regulation (EU) No 910/2014 of the European Parliament and of the Council.
7
Section II Security Services, section 6.4: “For this reason, even if the
transaction’s payload contains “healthcare-related data”, they WOULD NOT be
stored in any way in the Log.
Section II Security Services, section 6.6: “The purpose of the audit system is not
to store healthcare-related data within the transactions, which is why this type of
data should not be stored in any way on the systems.”
Findings
5. According to the Estonian Information Security Standard for public sector (ISKE),
information security policies have a hierarchical structure from national level down
to ministerial and agency level. These policy documents contain the relevant
elements expected from a security policy – with one exception. Quantifiable
indicators for the confidentiality and integrity dimensions of the e-Health project are
currently missing. Therefore, the processes of setting measurable targets to allow a
review of the achievement of those targets are not in place as required by
Requirements Catalogue 09.01, section 16 of the European Data Protection Board’s
Guideline 4/2019 and Clauses 5.2 (contents of security policy) and 6.2 (criteria for
information security objectives) of ISO 27001. [IS.2 – Major]
6. The audit team found that the current Information Security Risk Assessment is not
fit for achieving the objectives of Articles 24.1, 25.1, 32.1 and in particular, 32.2 of
the GDPR [IS.3, IS.4, IS.13, IS.14 – Critical]:
a. The Excel file containing the Risk Assessment was not clear and intelligible
enough for communicating the outcome to stakeholders e.g. management and
auditors;
b. The assessment could not demonstrate sufficient coverage of relevant risks, in
particular, risks arising from external threats. It also could not demonstrate
whether the mitigating measures are reducing the risk(s) to an acceptable level
or to the residual risk remaining after mitigating measures;
c. The assessment did not provide an overview (or analytical synthesis) of the
threats, vulnerabilities and impacts that were considered;
d. There was no evidence that the risk assessment resulted in concrete actions.
7. Generally, TEHIK uses strong two-factor authentication (with identification
schemes notified under Regulation (EU) No 910/2014) for health professionals. The
method(s) of authentication (and other security measures) are outlined in contracts
between TEHIK and Health Care Provider Organisations. There is currently no
process for verifying that all Health Care Provider Organisations comply with the
provisions of the contract as required by Requirements Catalogue 09.01, Article
32.1(d) of the GDPR and Clause II.4.1 of the Multilateral Agreement. [IS.24 –
Critical]
8
8. Apart from the strong authentication described above, there is an option for Health
Care Providers to authenticate using so-called IS-connector. This method does not
make use of the notified identification schemes (as described above) and therefore,
is not in line with the requirements of section 2.3 of the X.509 Certificates Profile
and section II.1.1.2(b) of the Multilateral Agreement. [IS.24 – Critical]
9. Configuration of Transport Layer Security (TLS) connections did not follow all of
the requirements of Section 8.1 of ECRYPT-CSA-2016 [IS.10 – Critical]:
a. TLS versions 1.0 and 1.1 were still allowed in some configurations;
b. Key length was lower than recommended in some cases;
c. Cipher Block Chaining (CBC) block cipher mode was allowed in some cases;
d. Secure Hash Algorithm 1 (SHA-1) was not explicitly disabled;
e. Rivest-Shamir-Adleman algorithm (RSA) was used for key-exchange (no
forward security);
f. Elliptic curve cipher suites included in configurations, although they cannot
be used with RSA certificates.
10. The NCPeH could not provide details on how the cryptographic keys are generated
i.e. demonstrate that keys are not generated using a weak generator as required by
Section 3.2.6 of ECRYPT-CSA-2016. [IS.10 – Critical]
11. Digital certificates used for authentication were generally in line with requirements,
with some exceptions [IS.10, T.6 – Critical]:
a. The NCPeH portal was using a certificate issued by a company (from United
States), which is not on the EU trusted list of trust service providers as
required by Section 2.3 of X.509 Certificates Profile; and
b. The validity of certificates exceeded the maximum of 2 years required by
Section 3.1 of X.509 Certificates Profile.
12. Security measures are verified by e.g. regular vulnerability scanning. However, a
formalised procedure for these scans is not in place and corrective actions from the
latest scan are still pending (after 3 months). Although this might pose a small risk
in pre-production environment, timely corrective actions would be required in
production environment in order to effectively implement the requirements of
Requirements Catalogue 09.01, Article 32.1(d) of the GDPR and Clause II.4.1 of the
Multilateral Agreement [IS.4, IS.8, IS.29 – Critical]
13. The auditee informed the audit team that Audit Trail logs contain also health related
information about the patients. This is not in line with sections 6.4 and 6.6 of
“Section II Security Services” specification v.3.0.0. [IS.7 and IS.31 – Critical]
9
Conclusions on information security management
The (pre-production environment) Information Security Management System is not yet
providing all the security assurances required for a production environment. The audit
team found non-compliances at policy, risk-assessment, implementation and review
levels. These have an impact on the “ongoing ability to ensure confidentiality” and on
the “process of regularly testing, assessing and evaluating the effectiveness of technical
and organisational measures”.
5.4 SERVICE OPERATIONS
Requirements
This section contains an assessment of compliance with the eHDSI requirements relating
to service operations for the new PS-A and PS-B services. The detailed applicable
requirements that were used in the audit were as follows:
Operations Framework, Section 3.7.2: “Objectives (of change management)
- To ensure that changes are recorded and then evaluated, authorized, prioritized,
planned, tested, implemented, documented and reviewed in a controlled manner;
- Overall business risk is optimized.”
Requirements Catalogue, 03.02: “The NCPeHs must ensure that all changes (legal,
organisational, technical, semantic) that occur to the cross-border services and their
assets are registered, analysed, resolved and their lifecycle must be traced.”
Operations Framework, Section 3.5: “The primary goal of Configuration Management
(CfM) is to identify, maintain, and verify information on IT assets and configurations.
CfM stores up-to-date information about Configuration Items (CIs) in a configuration
management database (CMDB). CIs are simply your IT infrastructure components, i.e.,
hardware, software, documentation, or even personnel. CMDB contain pertinent
information on CIs—for instance, version and location, as well as relationships between
CIs.”
Operations Framework, Section 3.5, Section 3.5.1: “ITIL Service Asset and
Configuration Management aims to maintain information about Configuration Items
(CIs) required to deliver an IT service, including their relationships.”
Operations Framework, Section 4.2: “There must be a monitoring and support
mechanism for ensuring continuing capacity (comply with principles and requirements
and perform according to expected service level’s) to be part of the CBeHIS
environment.”
Monitoring and reporting Framework, Section 2 – KPI-3.3: “More than 95%
availability (meaning that the system may be unavailable for 1.2 hours per day).”
PS Functional Requirement NFR03: “The system should provide an end to end
response time (as experienced by the country B HP) within a few seconds, possibly no
more than 10 seconds. (footnote: The technical groups will have to evaluate the
feasibility of this response time. It has to be understood that the 10 seconds limit is not a
10
service level agreement but a proposal of threshold.)” “The access times should be
tested continually by the system to give the user some idea of what to expect.”
Guidelines on minimum/non-exhaustive patient summary dataset for electronic
exchange in accordance with the cross-border Directive 2011/24/EU of the
European Parliament and of the Council: “In terms of education, training and
awareness raising, Member States should:
a) undertake activities towards increasing awareness of the benefits of and need for
interoperability and related standards and specifications for electronic crossborder
patient data exchange;
b) pay particular attention to education, training and dissemination of good practices in
electronically recording, storing and processing patient information as well as in gaining
the informed consent of the patient and lawfully sharing the
patient's personal data;
c) initiate appropriate, easy to understand information and awareness raising measures
for all individuals, in particular patients.
d) provide education and training for promoting a culture of high levels of security and
privacy.”
Guideline on an Organisational Framework for eHealth National Contact Point,
Section 3.2.1.5: “It is recommended that national training materials and activities be
provided to support CBeHIS operation.”
Findings
14. The configuration management tool (Excel table) did not contain up-to-date
configuration information. Not all assets were covered by the tool (e.g. DNS server)
and some configurations relevant to security were not recorded (e.g. TLS
configuration) as required by Section 3.5 of the Operations Framework. [OS.19 –
Major]
15. The change management process did not capture some changes relevant to
information security; changes required by a recent vulnerability scanning were not
recorded in the change management tool as required by section 3.2 of the
Operations Framework and Requirements Catalogue 03.02. [OS.2, OS.11, OS.12 –
Critical]
16. Monitoring of availability and response time of services e-Prescription A and e-
Prescription B indicate that a monitoring system is in place and targets are being
met. However, there are some challenges in measuring both availability and
response time [O.11, OS.21, OS.23 – Major]:
a. Availability is currently measured only as up-time of the server – server being
up and running does not guarantee that the service is available.
b. The indicator on response time does not provide for the total response time as
experienced by the health care professional as required by Patient Summary
(PS) Functional Requirement NFR03.
11
17. The current communication plan for stakeholder training and awareness was lacking
the necessary details to allow for effective implementation of the requirements in
the Requirements Catalogue 03 and “Guidelines on minimum/non-exhaustive
patient summary dataset for electronic exchange in accordance with the cross-border
Directive 2011/24/EU”. The current plan does not provide details such as: timelines,
duration of activities, specific objectives and activities, target groups and materials
used for training/communication).
Conclusions on service operations
As configuration and change management are not fully in line with requirements and
communication plan for stakeholders is still in progress, the new services are not yet
ready to go live.
5.5 QUALITY OF HEALTH DATA
Requirements
This section contains an assessment of compliance with the eHDSI requirements relating
to the transcoding (PS-A service) and translation (PS-B service).
Findings
The audit team had no findings in this area.
6 OVERALL CONCLUSIONS
Although the NCPeH organisation is well advanced in complying with the requirements,
work remains to be done in a number of areas. These refer to controllers’ and processors’
obligations, patients’ rights and freedoms, information security management system and
service operations, where non-compliances with the new services requirements create
some risks to the confidentiality and availability of patient data.
In addition, there were deficiencies in the monitoring of service availability and response
time, which may have an impact on availability. There were no findings indicating that
integrity would be at risk.
7 CLOSING MEETING
The audit team presented all findings at the closing meeting. Representatives of the
NCPeH did not raise any concerns in relation to the findings, except for the findings
related to patient consent where the NCPeH noted its disagreement with the audit team’s
interpretation of the requirements.
12
8 RECOMMENDATIONS
TEHIK is invited to provide details of the actions taken and planned, including deadlines
for their completion (‘action plan’), aimed at addressing the recommendations set out
below, within 15 working days of receipt of this report.
No Recommendation
1. To update the Data Protection Impact Assessment (DPIA) in order to cover
risks to all patient’s rights and in particular, to ensure that the DPIA provides
an assessment of the impact of the new services on all of the patient’s rights as
required by Article 37.1 and 37.7(c).
Associated finding: No 1
2. To ensure that PS-A service is based on consent, as required by
Interoperability and Identity Management specifications.
Associated finding: No 2
3. To ensure that the data controller can demonstrate that the foreign patient has
consented to the cross-border exchange of patient summary (in PS-B service),
as required by Article 7.1 of the GDPR, interoperability specification and
identity management specification.
Associated finding: No 3
4. To finalise the Patient Information Notices for PS-A and PS-B services as
required by business requirement 04.03 of the Requirements Catalogue.
Associated finding: No 4
5. To develop measurable indicators for confidentiality and integrity in PS-A and
PS-B services. The indicators should be suitable for setting measurable targets
and reviewing the achievement of targets on a regular basis.
Associated finding: No 5
6. To review and update the Information Security Risk Assessment in order to
ensure that relevant risks are covered, residual risks are at acceptable level and
that the results are presented in a clear and intelligible way.
Associated finding: No 6
7. To verify and demonstrate that all Health Care Provider Organisations comply
with the authentication requirements of the contract and to discontinue the use
of IS-connector for authentication.
Associated findings: Nos 7 and 8
13
No Recommendation
8. To ensure that all TLS connections are configured at least to the minimum
security level required by eHDSI requirements.
Associated finding: No 9
9. To ensure that cryptographic keys are not generated with a weak generator.
Associated finding: No 10
10. To ensure that all certificates are issued by Trust Service providers, which
appear on the EU Trusted List of trust service providers and that the validity
of certificates does not exceed two years.
Associated finding: No 11
11. To formalise a procedure for handling findings from vulnerability scans or
penetration tests in order to ensure that timely corrective action is taken.
Associated finding: No 12
12. To ensure that health-care related data is not included in (audit trail) logs.
Associated finding: No 13
13. To ensure that configuration and change management processes are in line
with requirements and suitable for achieving the objectives.
Associated findings: Nos 14 and 15
14. To improve the monitoring of service availability and response time.
Associated finding: No 16
15. To update the communication plan with necessary details and timelines in
order to be ready for rolling out awareness and training activities before and
after going live, as appropriate.
Associated finding: No 17
14
ANNEX 1 – LEGAL REFERENCES
Legal Reference Official Journal Title
Dir. 2011/24 OJ L 88, 4.4.2011, p. Directive 2011/24/EU of the European
45–65 Parliament and of the Council of 9 March
2011 on the application of patients’ rights in
cross-border healthcare
Reg. 2014/910 N/A N/A
Reg. 2016/679 OJ L 119, 4.5.2016, Regulation (EU) 2016/679 of the European
p. 1–88 Parliament and of the Council of 27 April
2016 on the protection of natural persons
with regard to the processing of personal data
and on the free movement of such data, and
repealing Directive 95/46/EC (General Data
Protection Regulation)
Ref. Ares(2021)2833831 - 28/04/2021
EUROPEAN COMMISSION
DIRECTORATE-GENERAL FOR HEALTH AND FOOD SAFETY
Health and food audits and analysis
Director
Grange
SANTE.F5 JJ/mmoc
Subject: Verification of implementation of corrective actions
Audit of Estonia carried out from 4 June to 16 October 2020 in order to
assess the National Contact Point for eHealth's readiness for joining the
Cross-Border eHealth Information Service Network for the new services
Patient Summary country A and Patient Summary country B
Ref.: DG(SANTE) 2020-7091
Dear Ms Reinhold,
I am writing to inform you that the audit team has now verified the implementation of the
actions taken in response to the recommendations made following the above-mentioned audit.
I am pleased to inform you that the audit team has concluded that all recommendations
(except for Nos 1 to 3) have been satisfactorily addressed. The audit team has proposed no
further request for information or other follow-up actions in relation to recommendations Nos
1 to 3, for the reasons indicated in the attached table.
Yours sincerely,
(e-signed)
María Pilar Aguar Fernández
Director
Enclosure: Annex
Ms Katrin Reinhold
Director
Health and Welfare Information Systems Centre (HWISC)
Veerenni 13/Uus-Tatari 25
10134 Tallinn
Estonia
European Commission, Grange, Dunsany, Co. Meath C15 DA39, Ireland - Office: GRAN 01/113
Tel.: direct line (+353 46) 9061 788, internal n°: 70788, switchboard: (+353 46) 9061 700. Fax: (+353 46) 9061 705
Ref. Ares(2021)2833831 - 28/04/2021
ANNEX
Commission services' assessment of the action plan submitted by the competent authorities of Estonia in response to Report ref. DG(SANTE) 2020-7091 of
the audit carried out from 04 June 2020 to 16 October 2020 in order to assess the National Contact Point for eHealth's readiness for joining the Cross-Border
eHealth Information Service Network for the new services Patient Summary country A and Patient Summary country B
N° Recommendation Action Proposed by the competent authority Commission services' assessment of the
competent authority's response
1 To update the Data Protection Impact Assessment DPIA will be amended by HWSICs legal While the amended DPIA still does not
(DPIA) in order to cover risks to all patient’s department and the Minsitry of Social Affairs provide for an assessment of the risks to
rights and in particular, to ensure that the DPIA by the end of March 2021. Please see patient's rights, pursuing this
provides an assessment of the impact of the new document “LISA 7”. recommendation is unlikely to be productive
services on all of the patient’s rights as required by for two main reasons:
Article 37.1 and 37.7(c). - The requirement is not specific enough (the
Associated finding: No 1 finding being about the achievement of the
objectives of an impact assessment).
- The underlying finding seems to be a
common occurrence in other Member States.
Therefore, Unit F5 proposes that no further
requests for information or other follow-up
actions are made in relation to this
recommendation.
2 To ensure that PS-A service is based on consent, Estonia is still in the situation where the While the situation in Estonia is considered
as required by Interoperability and Identity functional requirements of the service are non-compliant with the current eHDSI
Management specifications. against our national legislation and GDPR. A requirements, the audit team acknowledges
Associated finding: No 2 change proposal is being prepared for the that the requirements are under review and
alignment of eHDSI Requirements with EU that they are likely to change soon.
legislation and the Agreement between Therefore, implementation of a consent
National Authorities or National management process at this point in time
Organisations responsible for national contact would not be productive.
points. This also states “Requirements related
to the explicit consent as the single legal Therefore, Unit F5 proposes that no further
bases to be applied by MSs on the Cross- requests for information or other follow-up
Border health personal data exchange should actions are made in relation to this
Page: 1
ANNEX
Commission services' assessment of the action plan submitted by the competent authorities of Estonia in response to Report ref. DG(SANTE) 2020-7091 of
the audit carried out from 04 June 2020 to 16 October 2020 in order to assess the National Contact Point for eHealth's readiness for joining the Cross-Border
eHealth Information Service Network for the new services Patient Summary country A and Patient Summary country B
N° Recommendation Action Proposed by the competent authority Commission services' assessment of the
competent authority's response
be removed or updated in line with the legal recommendation.
provisions of the Agreement between
National Authorities or National
Organisations responsible for National
Contact Points for eHealth on the Criteria
required for the participation in Cross-Border
eHealth Information Services, the Directive
2011/24/EU and the GDPR.” Please see
document CP-Consent.docx
3 To ensure that the data controller can demonstrate Foreign patient can’t give his/her consent in This recommendation is linked to the
that the foreign patient has consented to the cross- country B, it has to be given prior the visit to previous one (No 2), and it will also become
border exchange of patient summary (in PS-B HCP via country A systems. This is explained redundant when the requirement on consent
service), as required by Article 7.1 of the GDPR, in the patient information notice, please see management has been reviewed and
interoperability specification and identity document “Patsiendi teavitamine PS-B amended.
management specification. EST_03.docx”
Associated finding: No 3 Therefore, Unit F5 proposes that no further
requests for information or other follow-up
actions are made in relation to this
recommendation.
4 To finalise the Patient Information Notices for PS- PINs will be finalised and published by the Satisfactory.
A and PS-B services as required by business end of March 2021 by HWSIC
requirement 04.03 of the Requirements Catalogue. Please see documents “Patsiendi teavitamine The PINs must be translated into official
Associated finding: No 4 PS-B EST_03.docx” and “Patsiendi languages of the Member States, which are
teavitamine PS-A EST_03.docx” currently providing PS-A service.
5 To develop measurable indicators for When it comes to monitoring integrity and Satisfactory.
confidentiality and integrity in PS-A and PS-B confidentiality, in some cases, we have
Page: 2
ANNEX
Commission services' assessment of the action plan submitted by the competent authorities of Estonia in response to Report ref. DG(SANTE) 2020-7091 of
the audit carried out from 04 June 2020 to 16 October 2020 in order to assess the National Contact Point for eHealth's readiness for joining the Cross-Border
eHealth Information Service Network for the new services Patient Summary country A and Patient Summary country B
N° Recommendation Action Proposed by the competent authority Commission services' assessment of the
competent authority's response
services. The indicators should be suitable for quarterly checks on the assigned rights that The plan to further develop indicators is
setting measurable targets and reviewing the are given to users, also all activities are adequate. In the absence of specific
achievement of targets on a regular basis. logged and therefore it is possible to identify requirements, it is up to the NCP to decide
Associated finding: No 5 wrongdoings in the information systems. The the best way to develop indicators.
best way to monitor integrity and
confidentiality is with incidents.
Additional indicators checking the incidents
will be added to the service pass by mid April
2021.
6 To review and update the Information Security An additional risk assessment will be Satisfactory.
Risk Assessment in order to ensure that relevant conducted by the end of March 2021 by an
risks are covered, residual risks are at acceptable outer party. The plan to further develop the Risk
level and that the results are presented in a clear Please see documents attached TEHIK Assessment is adequate. Nevertheless,Unit
and intelligible way. riskianalüüsi aruanne.docx and Lisa 3. F5 would like to leave it on record that it is
Associated finding: No 6 Riskianalüüsi tabel.xlsx not in a position to determine whether this
new Risk Assessment is fit for purpose.
7 To verify and demonstrate that all Health Care IS-connector will be removed from the Satisfactory.
Provider Organisations comply with the project for the mentioned security reasons.
authentication requirements of the contract and to Amended architecture scheme will be The corrective action is satisfactory and fully
discontinue the use of IS-connector for available mid April 2021. addresses the recommendation.
authentication.
Associated findings: Nos 7 and 8
8 To ensure that all TLS connections are configured TLS connection configurations will be Satisfactory.
at least to the minimum security level required by rechecked against the eHDSI requirements
eHDSI requirements. and regular scans will be discussed and The proposed action is adequate in
Associated finding: No 9 documented by the end of March 2021. addressing the recommendation.
CEF scan is defined in HWISC cybersecurity
Page: 3
ANNEX
Commission services' assessment of the action plan submitted by the competent authorities of Estonia in response to Report ref. DG(SANTE) 2020-7091 of
the audit carried out from 04 June 2020 to 16 October 2020 in order to assess the National Contact Point for eHealth's readiness for joining the Cross-Border
eHealth Information Service Network for the new services Patient Summary country A and Patient Summary country B
N° Recommendation Action Proposed by the competent authority Commission services' assessment of the
competent authority's response
environment
https://spot.tehik.ee/display/TEH/INFOTUR
BETEENUSED -> Turvanõrkuste
skaneerimine (access limited). In addition, the
information has been added to the service
pass, document teenuse_pass.pdf, paragraph
6.2.4 Turvanõrkuste skaneerimine. The
results of the vulnerability scan will show us
the protocols in use. From there on we will
continue our change management process (if
necessary), document the results in Jira and
proceed with the TLS connections alignment
with eHDSI requirements.
9 To ensure that cryptographic keys are not Generating the cryptographic keys is based Satisfactory.
generated with a weak generator. on HWISC cryptoconcept point 4.4. Since
Associated finding: No 10 they are generated by OpenSSL software we The planned action is adequate in addressing
assume that it is safe (until proven otherwise). the recommendation.
For checking the length of the keys we will
add additional controls to monitoring, so that
the keys will match the requirements in
cryptoconcept, which will be done by the end
of February 2021 by HWISc monitoring dep.
Please see documents Zabbix (monitoring
screenshot on the example of cross border
ePrescription) and script
external_checks_ssl_check.py
10 To ensure that all certificates are issued by Trust A new service provider (from the EU trusted Satisfactory.
Page: 4
ANNEX
Commission services' assessment of the action plan submitted by the competent authorities of Estonia in response to Report ref. DG(SANTE) 2020-7091 of
the audit carried out from 04 June 2020 to 16 October 2020 in order to assess the National Contact Point for eHealth's readiness for joining the Cross-Border
eHealth Information Service Network for the new services Patient Summary country A and Patient Summary country B
N° Recommendation Action Proposed by the competent authority Commission services' assessment of the
competent authority's response
Service providers, which appear on the EU list) for the NCPeH portal will be added by
Trusted List of trust service providers and that the the end of March, which also includes a new The action is adequate in addressing the
validity of certificates does not exceed two years. certificate. recommendation.
Associated finding: No 11 We have sent a request to the head of HWISC
Information Systems Administration
Department in order to get a new certificate,
but it is still pending. New information will
be available in the beginning of April 2021
11 To formalise a procedure for handling findings The regularity of the scans will be described Satisfactory.
from vulnerability scans or penetration tests in in HWISCs internal system SPOT and by the
order to ensure that timely corrective action is end of February 2021. The action is adequate in addressing the
taken. CEF scan is defined in HWISC cybersecurity recommendation.
Associated finding: No 12 environment
https://spot.tehik.ee/display/TEH/INFOTUR
BETEENUSED -> Turvanõrkuste
skaneerimine (access limited). In addition, the
information has been added to the service
pass, document teenuse_pass.pdf, paragraph
6.2.4 Turvanõrkuste skaneerimine.
12 To ensure that health-care related data is not Comment from the auditors: The requirement Satisfactory.
included in (audit trail) logs. is using the term “healthcare-related data”,
Associated finding: No 13 which might be a bit open for interpretation. The explanation provided is sufficient to
What it definitely means, is that medical address the recommendation. For the file, if
information from patient summary should not this information had been provided during
be there. Some information about the health the audit, there would have been no need to
care provider might be necessary to provide issue a recommendation.
for non-repudiation and possibly other
Page: 5
ANNEX
Commission services' assessment of the action plan submitted by the competent authorities of Estonia in response to Report ref. DG(SANTE) 2020-7091 of
the audit carried out from 04 June 2020 to 16 October 2020 in order to assess the National Contact Point for eHealth's readiness for joining the Cross-Border
eHealth Information Service Network for the new services Patient Summary country A and Patient Summary country B
N° Recommendation Action Proposed by the competent authority Commission services' assessment of the
competent authority's response
functionalities – including the abuse detection
system. So, in summary we could say that we
can live with storing health-care professional
data but definitely not data concerning the
medical details of a patient.
HWISC: we have only included the health
care professional data in ATNA logs, but not
the patients, so this finding should not be a
finding.
13 To ensure that configuration and change Changes required by vulnerability scan were Satisfactory.
management processes are in line with not captured in change management, but will
requirements and suitable for achieving the be resolved with the solution of a finding no The planned action adequately addresses the
objectives. 12. recommendation.
Associated findings: Nos 14 and 15 Events, incidents and problems will be
identified more thoroughly by mid April 2021
by HWISC quality management.
14 To improve the monitoring of service availability Monitoring and service availability will be Satisfactory.
and response time. improved after we have a new partner from
Associated finding: No 16 the procurement process (should happen in The planned action adequately addresses the
February 2021) by mid April 2021. recommendation.
15 To update the communication plan with necessary Communications plan will be updated by the Satisfactory.
details and timelines in order to be ready for end of March 2021 by HWISC
rolling out awareness and training activities before communication team, please see document The planned action satisfactorily addresses
and after going live, as appropriate. attached “CPTP-2.3.Teavitustegevused.pdf”, the recommendation.
Associated finding: No 17 patient summary information starting from
“Tegevused Eesti riik A ja B vaatest
Page: 6
ANNEX
Commission services' assessment of the action plan submitted by the competent authorities of Estonia in response to Report ref. DG(SANTE) 2020-7091 of
the audit carried out from 04 June 2020 to 16 October 2020 in order to assess the National Contact Point for eHealth's readiness for joining the Cross-Border
eHealth Information Service Network for the new services Patient Summary country A and Patient Summary country B
N° Recommendation Action Proposed by the competent authority Commission services' assessment of the
competent authority's response
(patsiendi terviseandmete kokkuvõtte saatja
ja vastuvõtja riik)”
Page: 7
To the eHealth Network
via
eHMSEG Secretariat (
[email protected])
Subject: Overall Readiness Statement to Start Production Environment Tests
On behalf of Health and Welfare Information Systems Centre (HWISC) I declare that our
National Contact Point for eHealth is ready to join the Cross border eHealth Information
Services providing the Patient Summary services as Country A and B.
This readiness and adherence of the National Contact Point for eHealth to legal, organizational,
semantic and technical criteria is demonstrated by the successful outcome of testing and
auditing:
1. Outcome Summary Test Report Wave 3,
2. Final audit report + assessment of action plan + verification of implementation of
corrective actions,
I attach to this statement proof of signature of the Agreement between National Authorities or
National Organisations responsible for National Contact Points for eHealth on the Criteria.
I undertake to notify the eHealth Network immediately of any change that could have a
significant influence on the validity of the above statement.
Therefore, I apply for joining the Cross-Border eHealth Information Services – Go Live.
Tallinn, 28.05.2021
Signed digitally
Katrin Reinhold
Director of Health and Welfare Information Systems Centre