CEN/ISSS Workshop on Interoperability of the electronic European Health Insurance Cards (WS/eEHIC)

Transcription

1 CEN/ISSS Workshop on Interoperability of the electronic European Health Insurance Cards (WS/eEHIC) Draft Business Plan (version 0.4) Status: for approval at Workshop kick-off meeting 1. Background As of 1 June 2004, European citizens travelling within the European Economic Area (European Union, Norway, Iceland and Liechtenstein) and Switzerland, whether for private or professional reasons, are being issued with a European Health Insurance Card, which simplifies the procedure for receiving any medical care that might become necessary during a temporary stay in another country 1. The European Health Insurance Card, which replaced the paper forms E111, E110, E 128 and partially E 119 2, in its present phase (eye-readable only), represents a first step towards simplification, which is essential in order to study and start preparing procedures for the electronic exchange and processing of data via the European Health Insurance Card. A second step towards simplification is an electronic EHIC: 1. which can be electronically read in the premises of the Healthcare Providers (general practitioners, pharmacists, hospitals, dentists ) equipped with the appropriate card reader and 2. whose validity can, under certain conditions and depending on the Member States 3, be verified on-line. This has been mentioned for the first time in the Communication of the European Commission 2003/0073 Final concerning the introduction of a European health insurance card 4. Other technological solutions may be possible such as mobile phones as media carrying the data, scanning of the card with OCR tools etc. but this is out of the scope of the work done here. The Administrative Commission for Social Security for Migrant Workers (called CA.SS.TM) has then agreed upon common principles and starting points for further work on the introduction of the electronic European Health Insurance Card 5 (eehic). These are in set at in Annex 1. 1 More information is available at 2 Emanating from the European Regulations coordinating social security Council Regulations (EC) 1408/71 and 574/72 3 The eehic system will indeed have to support different situations in parallel, where some Member States will have bilaterally agreed to electronically check the validity of their card or the entitlement of their insured persons, while others will only visually check the validity of the card. 4 COM(2003)73 final ECOJ 27 February See CA.SS.TM note 163/05 REV. 1

2 In the 27th Meeting of the Technical Commission on Data Processing termed TC (a sub-group of the Administrative Commission for Social Security for Migrant Workers) of 22 & , it was decided to create an ad hoc working group with the mandate to develop an EU standard for interoperability of electronic European Health Insurance Cards (eehic). The work of this Ad Hoc Group led, the end of 2006, to a draft Reasoned Opinion (CA.SS.TM Note 340/06) submitted to TC as an interim deliverable. The final report is expected to be delivered by mid Once approved by the TC, it is expected that this report will serve as basis for the Administrative Commission, supported by the TC to work out a set of draft formal Decisions of CA.SS.TM which will define all conditions for the deployment of the eehic system and which, once approved by the CA.SS.TM, will become the legal basis for its deployment 6. CA.SS.TM Note 340/06 defines the foundations for further discussions within and outside the group. It assesses the technical feasibility of setting-up the necessary infrastructure for eehic and defines an approach for ensuring affordability and sustainability. When available the final report of the ad-hoc group will replace CA.SS.TM Note 340/06 in this function. 2. Workshop originators The Workshop is proposed by the European Commission, DG Employment acting as Secretariat of the Technical Commission on Data Processing (a sub-group of the Administrative Commission for Social Security for Migrant Workers CA.SS.TM). 3. Workshop purpose, objectives and scope The objective is to develop and publish a CEN Workshop Agreement (CWA) which will identify and propose to the Technical Commission all the specifications necessary for deploying the eehic system as defined in CA.SS.TM 340/06 and the final report of the eehic Ad Hoc Group. This CWA should be designed with a view to its content becoming the annex of one of the formal CA.SS.TM Decisions deciding upon the creation of the eehic. This objective of the CWA will have to be achieved in two steps: 1. To review, complement and validate the list of available or required standards (Inventory phase) 2. To standardize the missing necessary specifications through the CWA (standardization phase) 4. Workshop work programme 6 It should be mentioned that this expected procedure of CA.SS.TM. Decision does not differ from the procedure applied for the launch of the current eye-readable EHIC. 2

3 The Workshop will run in two phases. The first phase (Inventory) will be a fact finding exercise. A report, validated by the Workshop, containing the list of available or required standards with a review of their completeness and identifying the missing necessary specifications, will be available in September 2007, so that it can be presented to the TC and discussed with CA.SS.TM during months October-December The Workshop will start up the second phase (Standardization) after it has received the conclusions drawn by the TC. This second step phase is expected to start in January 2008, and will deliver at the latest by April These dates are however dependent on timely feed-back by the CA.SS.TM in December Phase 1 Task 1: Launching the CEN Workshop Task 2: Selecting the Project Team Task 3: Project Team starts drafting Task 4: Initial version of the Phase1 report available to Workshop Task 5: Workshop validation meeting Task 6: Delivery of final report of phase 1 to EC/EFTA and CA.SS.TM Phase 2 Task 7: Workshop meeting receiving/discussing feed-back by CA.SS.TM Task 8: Project Team drafts first (still incomplete) version of the CWA Task 9: Workshop meeting receiving/discussing first draft CWA Task 10: Project Team drafts revised version of the CWA (complete text) Task 11: Workshop meeting receiving/discussing second draft CWA Task 12: Project Team produces final text of the CWA Task 13: Final draft CWA for 60 days public review (including those from WS) Task 14: Final Draft including comments received Task 15: Workshop meeting approves CWA (if necessary followed by a final electronic process) Task 16: Submission of the final report (CWA) to EC/EFTA and CA.SS.TM 5. Workshop organization and timescale The Workshop is proposed with a duration of 28 months, starting from January The kick-off meeting will be held at CEN in Brussels on 24 April Six Workshop meetings are foreseen (2 for the first phase and 4 for the second phase). Task Milestone Month Note T1 CEN WS launch Kick-off meeting Jan- April 2007 T1-T6 is Phase 1 Inventory T2 Selection PT Beg. May 2007 T3 PT starts drafting May-Aug T4 Interim Rep. to WS End Aug T5 WS validation meeting 2 nd plenary Mid Sept

4 T6 Final Rep. to EC/EFTA and CA.SS.TM Report to CA.SS.TM for comments, expected by Dec 2007 T7 WS discusses feed-back CA.SS.TM meeting 3rd plenary meeting End Sept January T8 PT producing 1st draft Feb-April 2008 T9 WS discusses 1st draft 4th plenary May 2008 meeting T10 producing 2 nd draft June-Aug.2008 (complete text) T11 WS discusses 2 nd draft 5th plenary Sept meeting T12 PT producing 3 rd draft Oct CWA (draft for public comment) T13 60 days public review of Nov.-Dec draft CWA T14 PT producing final draft January 2009 CWA (text for publication) T15 CWA approval 6th plenary February 2009 meeting T16 Final report (including final CWA) to EC/EFTA and CA.SS.TM. April 2009 T7-T16 is Phase 2 : Standardization The Workshop will take due account of the comments made by the DG Employment s eehic Ad Hoc Group and subsequent group mandated to do so by the TC/CA.SS.TM. The DG Employment s eehic Ad Hoc Group and subsequent group might request additional drafting on the CWA if not satisfied with the content, taking into account the resources available. 6. Resource requirements The Workshop eehic shall work on a voluntary basis. There is no fee for participating in the Workshop and participants shall bear their travel expenses for attending meetings 8. The Workshop will have a Chair, who will work on a voluntary basis, and a Secretariat, which is a CEN member and is supported via EU/EFTA funding. 7 The dates from here onwards depend on the timely delivery of comments on the First Phase Final Report from CA.SS.TM. 8 To register as Workshop member, an on-line form is available on the CEN web site at the URL: in the page about Workshop eehic. 4

5 The Workshop will be supported by one Project Team composed of 3 experts, for which EU/EFTA funding is available. The expertise required for the Project Team, the condition for work and the timescale and procedure for the Project Team selection are contained in the document Terms of Reference for the CEN/ISSS WS/eEHIC Project Team 9. This document has been drafted by CEN Pre Standards in collaboration with representatives of the DG Employment s eehic Ad Hoc Group and DG Employment. 7. External liaisons The Workshop eehic will liaise with: CEN TC 224 CEN TC 251 CEN Advisory Board on Healthcare Standards (ABHS) ETSI ehealth Project Members of DG Employment s eehic Ad Hoc Group and any subsequent group mandated to do so by the TC/CA.SS.TM will be invited to participate actively in the Workshop. In addition, participation of consumers as well as healthcare provider representatives will be sought to ensure the outputs take current developments into account in an optimal manner. Standardization work will also take into account the results of several ongoing research and development projects, at European and national level, which already are studying the introduction of electronic European Health insurance card. Liaison with other standards groups might be added during the Workshop activity. 8. Contact points The Workshop Chair will be appointed by the Workshop members at the Workshop kick-off meeting. DG Employment s eehic group will propose a candidate for the Chairmanship. The Workshop Secretariat will be carried out by AFNOR, the French Standards Organization, subject to endorsement of the Workshop at the Workshop kick-off meeting. Workshop Chair: To be appointed 9 The document referred to here is Terms of Reference for the CEN/ISSS WS/eEHIC Project Team (doc 003), available in February 2007 at the URL: under the heading Call for experts. The draft Terms of Reference are to be approved at the Workshop eehic kick-off meeting on 24 April

6 Workshop Secretary (tbc): Ms. Alice Rideau AFNOR Normalisation rue Francis de Pressensé, 11 F Saint-Denis La Plaine Cedex France tel +33 (0) fax +33 (0) CEN Programme Manager: Ms. Barbara Gatti CEN Pre Standards Rue de Stassart, 36 B-1050 Brussels Tel Fax barbara.gatti@cen.eu 9. Annexes 1) Common principles and starting points for the creation of the eehic Agreement of the Administrative Commission and the Technical Commission. (CA.SS.TM 163/05 REV) 2) Proposal for a TC Reasoned Opinion on the eehic architecture (CA.SS.TM. 340/06) 6

7 ANNEX 1 EUROPEAN COMMISSION EMPL/998/05 - EN CA.SS.TM 163/05 REV eehic SECRETARIAT 21/10/2005 Orig. EN TC 25/05 ADMINISTRATIVE COMMISSION ON SOCIAL SECURITY FOR MIGRANT WORKERS Subject: Common principles and starting points for the creation of the eehic Agreement of the Administrative Commission and the Technical Commission. Note from the Secretariat of 21 October 2005 The Administrative Commission and the Technical Commission are agreed upon the following common principles and starting points for the further work on the introduction of the electronic European Health Insurance Card (eehic): 1) The introduction of the eehic will take place when the Plan of Action of the Technical Commission and the new implementing Regulation are completed. 2) The national situations, the card projects in particular, will frame the development of the eehic. 3) The experiences with the use of the current EHIC should be made use of for the introduction of the eehic. 4) In depth analysis has to be carried out on (a) the circulation of the E 1xx forms and (b) costs/benefits of the introduction of the eehic. 5) The contents of the information exchanges linked to the use of the eehic may not be determined yet, this aspect will be studied later on the basis of a gradual approach. 6) The electronic verification of the validity of the card is a central element of the eehic. 7) The common objective is to have an eehic with an European interoperability; each Member State can achieves this in its own time without obligations. *** 7

8 In line with these principles, the Technical Commission on Data Processing should perform the following tasks during 2005 and 2006: * to update the note on the national card projects published in 2003 * to take into consideration the conclusions of the Administrative Commission on the experiences on the introduction of the EHIC (note CASSTM 094/05) * to analyse the circulation of the forms E 1xx in depth * to carry out a cost-benefit study on the introduction of the eehic * to define European interoperability 8

9 ANNEX 2 EUROPEAN COMMISSION EMPL/00/06 - EN CA.SS.TM. 340/06 Proposal for a TC Reasoned Opinion on the EHIC architecture FINLAND, GERMANY & SECRETARIAT 28/11/2006 ORIG: EN TC 46/06 ADMINISTRATIVE COMMISSION ON SOCIAL SECURITY FOR MIGRANT WORKERS Subject: Proposal for a TC Reasoned Opinion on the eehic architecture Note from Finland, Germany and the Secretariat of 28 November 2006 At its most recent meeting (15-16 November, in Athens) the AdHoc Group on the eehic reached a consensus on some parts of the document called Summary of Agreement (Section 2.1 and 2.2 as drafted in its version 0.32) and is now proposing the TC to adopt a Reasoned Opinion on what the basic architecture of eehic should look like when the Administrative Commission comes to a decision on organising the large scale deployment of electronic European Health Insurance Cards for the Member States. This reasoned opinion is a first milestone and is intended to provide the TC with the foundations for further discussions. It assesses the technical feasibility of setting-up the necessary infrastructure for eehic and defines an approach for ensuring affordability and sustainability. By no means is it an endresult of the Ad Hoc group activities. 9

10 Proposed Reasoned Opinion on the eehic architecture 1. This Reasoned Opinion sets architecture guidelines for eehic deployment, taking into account the agreed principles as stated in CA.SS.TM Note 163/05(i.e. Principles No 1, 2, 3, 6 and 7). It is proposed for adoption by the Administrative Commission without prejudice of a future Decision of the Administrative Commission on the terms and conditions of a large scale deployment of electronic European Health Insurance Cards by the Member States. 2. The proposed eehic architecture is designed in a way that it could take advantage of existing national and regional (card) systems capturing the cost saving effects related to that. By doing so the eehic architecture names key elements for an interoperable platform. 3. Any existing microprocessor card used as an eehic will also have to carry eye readable EHIC information. 4. It is recognised that in the long term a common standard specification for the eehic will be the preferred solution but that in the short and mid term it will be necessary to support the existing national / regional cards to some extent. 5. Horizontal European activities relevant to the scope of the eehic need to be monitored. Scenarios 6. This architecture provides solutions only for the scenarios where a health care provider 10 is equipped with the necessary infrastructure to read the card and is asked to provide health care to a patient insured in another Member State holding an eehic. 7. The eehic architecture supports coexistence of these scenarios with other scenarios which do not directly fall under the mandate of the ad hoc group. a. The scenario where the same health care provider is asked to provide care to a patient insured in another Member State and holding a non-electronic (but eye-readable) EHIC is not supported by the proposed architecture. They could probably be supported when some additional enhancements (e.g. a scanner) are introduced in the infrastructure of the Health Care Provider. b. The scenario which involves health care providers not equipped with any infrastructure to read cards is not covered by this architecture. Call centres have been identified as a possible solution for this kind of situation. Data 8. The EHIC data set as defined in Decisions 189 and 190 constitutes the minimum dataset to be included on the micro-processor card for serving as a European Health Insurance Card. 9. This data set does not require any privacy measures to be implemented on the card (no need for a PIN or for a health professional card for authorising access to the data). eehic infrastructure 10. The eehic infrastructure includes a number of national environments and one European environment. The infrastructure of the national/regional environments includes the infrastructure in place at the health care provider site and the communication infrastructure. The European environment includes the necessary software and hardware required for enabling the national/regional environments 10 The term Health Care Provider (HCP) is understood in a broad sense in this document. The terms refer indeed to the institution where a treatment is provided and the subsequent administrative procedure performed. A Health Care Provider may therefore be (1) a general practitioner, family doctor, (2) the admission/registration desk of a hospital or a clinic, (3) a nurse, a pharmacist, a dentist 10

11 to interoperate at European level. The new Electronic Exchange of Social Security Information project (EESSI) will have to offer all the services to be included in the European environment. 11. Each member state is responsible for organising the relationship between the health care providers and EESSI. 12. Each Member State is responsible for its own security policy under national legislation. Since some of the data provided by the competent institutions fall under privacy regulations, a common security policy needs to be agreed upon. 13. Each issuer of a microprocessor card intended to serve as an eehic is responsible for providing the means required for reading that card. 14. A verification of the validity of the entitlement is desirable where possible. Checking the validity of the card can be a supporting measure. 15. The usage of the eehic can be off-line or on-line where the on-line solution is able to offer additional services. Off-line eehic solution 16. The off-line eehic solution as described in Annex 1 enables a health care provider to read the electronic EHIC dataset on all the cards issued in other Member States and designed to serve as an eehic. 17. If needed verification of the origin (in terms of the issuing institution) and of the authenticity of the electronic dataset on the eehic can be performed when the EHIC dataset is electronically signed. 18. In an off-line scenario checking of the card validity and / or the entitlement of the card holder cannot be performed. On-line eehic solution 19. An eehic on-line solution as described in Annex 2 is needed in case it is necessary or desirable to obtain more up-to-date or additional data or services e.g. from the competent Member State. For the eehic itself services might be desirable for verifying the validity of a card or the entitlement of a person. 20. The same solution could provide optional supplementary data services, e.g. for providing data such as the status of pensioner. It can also be an enabler for further paper-flow re-engineering. 21. The eehic on-line solution will have to be supported by the EESSI system in order to securely interconnect the national/regional infrastructures (e.g. through TESTA). In order to manage the eehic related transactions inside that EESSI infrastructure a national Access Point is needed. 22. Appropriate communication and security measures must be in place within the national/regional environments to support the processes of authenticating access requesters (i.e. the health care professional), validating access rights and securing access to the services mentioned in no 17 and This Reasoned Opinion together with the version of the Summary of Agreements document in its version current at any one time are to be used as input for the planned CEN workshop on standards for the eehic. eehic as a part of a general EESSI infrastructure 24. Everything stated so far is related to the role of the EHIC as it stands for the time being. Possible additional roles for an eehic in the perspective of an EESSI infrastructure need to be defined and may lead to additional requirements on the microprocessor card as such and on the various infrastructure elements. This topic is not covered by the current mandate of the group. Legal aspects 25. The issue of the current legal framework not fully covering the solution described in this document has been addressed in CA.SS.TM 219/06. 11

12 Financial aspects 26. Only after having agreed on the main architecture elements as defined in this Reasoned Opinion will it be possible to carry out an investment analysis. 12

13 Annex 1: Off-line and on-line architecture for eehic From a conceptual point of view, the on-line eehic architecture is made up of the following building blocks: A card layer made up of o A physical card with a microprocessor and its operating system o A set of data used for national application o The EHIC data set An infrastructure layer which includes o A user access point, made up of a card reader and a PC-based workstation running the reading software and EHIC related application which process the data read out from the card Only in case of an on-line infrastructure o The necessary communication facilities (e.g. telephone line, the Internet) o An Access Point, i.e. a server in charge of managing the authentication process of the access requester (i.e. the health care professional) and authorizing or refusing the access to the data base or the service (i.e. eservice) o A card status authority - not necessarily based on PKI technologies - which may include an up-to-date list of invalid cards (revocation list/black list) and/or authenticates the access requester (i.e. the health care professional) An eservice layer which includes o The Access authorisation mechanism o The back office application, database or services, with the entitlement data of an insured person. Infrastructure Layer Card Status Authority Card Layer eservice Layer eehic data National data HCP Workst. Access Point Entitlement db Figure 1: Off-line/On-line eehic architecture 13

14 Annex 2: Processes for the off-line/on-line architecture for eehic The technical processes required for reading the data out of an unprotected eehic card issued in another Member State and verifying the entitlement of the card holder can be schematised as follows: 1a: Card activation 1b: Card recognition, including the selection and upload of the appropriate application for reading the card 1c: Securing the communication card/reader 1d: [Verifying the signature of the EHIC data set] 2: Postponed till after performing the 7th process 3: Reading out the card Only in case of an on-line infrastructure 4: Connecting to Access Point in a secure manner 5: Requesting the authentication of the access requester (optional) 6: Answering the authentication request (optional) 7: Identifying, authenticating and connecting the appropriate access point 2: Validating the card 8a: Validating access right to the eservice layer 8b: Verifying entitlement of the card holder or downloading complementary data Home Member State Infrastructure Layer Card Status Authority Card Layer 2 eservice Layer eehic data National data Access Point 8 EHIC data Entitlement db HCP Workst. 4 Access Point 5 6 Host Member State Card Status Authority Figure 2: On-line eehic architecture and processes Remark 1: The processes represented in blue in the above figure are those processes which need to be specified for interoperability purpose. As such, they are part of the European Domain. Remark 2: The relevance of this architecture has been demonstrated by the NETC@RDS project. 14

15 From a conceptual point of view, the HCP workstation capable to use reading software for different cards issued in another Member State can be represented as in the below figure. Infrastructure Layer Home Member State Access Point HCP Workstation Applic. Applic. Card A Card B Applic. New Card a b Access Point Common application 5 6 Host Member State Card Status Authority Figure 3: Zoom on the HCP workstation and related supportive measures This figure also identifies the supportive processes belonging to the European Domain that are required for enabling the workstation reading out data from various these cards: a): Calling the national access point for up-to-date verification of the loaded reading software for a particular card and download as necessary b): Routing and forwarding the call to the appropriate foreign access point for verifying update and downloading it as required. 15