Cen isss eehic cwa
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

CEN ISSS eEHIC CWA PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

CEN ISSS eEHIC CWA. Pantelis Angelidis – on behalf of the CEN/ISSS/WS & PT. Background. Project:"Electronic European Health Insurance Card “ Documents : PHASE A:Review and validation of the available or required standards for the eEHIC (approved 12-02-2008)

Download Presentation

CEN ISSS eEHIC CWA

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Cen isss eehic cwa

CEN ISSS eEHIC CWA

PantelisAngelidis – on behalf of the CEN/ISSS/WS & PT


Background

Background

Project:"Electronic European Health Insurance Card “

Documents :

PHASE A:Review and validation of the available or required standards for the eEHIC (approved 12-02-2008)

PHASE B:CWA (approved 10-03-2009)

White Paper


E ehic background and context

eEHICbackground and context

  • The main features of an electronic EHIC are :

    • It will carry the same dataset in electronic form that is defined by the data printed on the outside of the EHIC,

    • it will be electronically read in the premises of the Health Care Providers equipped with appropriate technology

    • its validity as well as the entitlement of the card holder could, under certain conditions and depending on the Member States, be verified on-line.


Phase a decisions cwa guiding principles 1 2

Phase A decisions  CWA guiding principles (1/2)

  • The basis of the work will be the well-known smart card standards (already used as credit/debit cards, phone cards etc., ISO7816 series)

  • The definitions of the health information related standards are used because they already closely reflect the EHIC dataset (e.g. ISO 21549)

  • The use of the Unicode character set where possible. This would practically mean support for all official EU languages and character sets.


Phase a decisions cwa guiding principles 2 2

Phase A decisions  CWA guiding principles (2/2)

  • In order to facilitate read-out from “new” smart cards as well as from already existing smart cards not yet supporting the standardised storage format, the CWA uses the “metadata approach”. This means that applications use metadata (machine readable card capability descriptions) when accessing an eEHIC. The interoperability framework is provided in this case by the ISO/IEC 24727 series.

  • The CWA provides a mechanism to protect the electronic exchange of the data.


Eehic on line through eessi

Social Security

Institution

Home Member State

National (Social Security) Network

National (Social Security) Network

EESSI

Network

Health Care Professional

eEHIC

Host Member State

Social Security

Institution

eEHIC on-line through EESSI


Iso 24727 definition of a card services

Client-Application

Service Access Layer

The client-application has a preset view on the card-application : only card services exposed by the ACD are visible.

Discovery data

Application 1

ACD

ISO 24727 : Definition of a card services


Eehic model basics

eEHIC Service front-end

MemberState’sFront End

National Repository

EU Country « B »

EESSI infrastructure

(EU Network)

EESSI (EU Network)

EESSI

National network

HCP

HCP workstation :ISO 24727-based

application layer & interface device layer

Application layer

EU Country « A »

Reader(s)

IFD

Token(s)

eEHIC from EU Country « B »

eEHIC - Model basics


Schematic view of middleware layout for eehic

Schematic view of middleware layout for eEHIC


Eehic cards types

eEHIC cards Types

  • ISO/IEC 24727 compliant eEHIC cards :

    • A completely new implementation, referred to as Type “1”.

    • A Card pointing to an XML-based Card-Info-File where the EHIC data are stored (outside of the card), referred to as Type “2”.

    • An existing Card which adds the eEHIC service to its list, referred to as Type “3”.

  • NON-ISO/IEC 24727 cards : Existing (legacy) card that does not support ISO/IEC 24727 and that stores the required data in a remote repository, referred to as Type “4”.


Eehic personalization main steps

eEHIC Data

eEHICHCP DID

eEHICADMIN DID

eEHIC personalization : main steps

?

3

?

?

4

..300C0405….

6

2

7

5

?

?

1

new card ?

Legacy card ?


Reminder discovery information management

ACD

ACD

application

ACD

DID

ACL

ACL

DID

DataSet,DSI

DataSet,DSI

Reminder : « Discovery information » management

SAL-API

personalization

Shareable e-Service

Service Access Layer

(SAL)

DER-TLV encoding

ISO 24727 container

ISO/IEC 7816-15

ASN.1 definition acc. ISO 24727 Part 2

ISO/IEC 7816-4


Communication flow description in cwa clauses

ISO 24727 compliant

Legacy

eCard

eEHIC

Communication flow description in CWA clauses

1

2

3

MS Authentication Proxy

MS’s DB

Client application

§ 7

Optional

Card authentication

Network

SOAP Webservices

§ 6

functional messages

HCP Application

ISO 24727-3 Application interface

Action Request/Response

§ 5

Card discovery, dataset read

SAL

Generic APDU

ISO 24727-2 Generic card interface

Generic Request/Response

ISO 24727

GCAL

ACD

CCD

CIA

CardInfo

Specific APDU

Specific Request/Response


End to end communication sequence card type 1 2 3 iso 24727 compliant

ReadCardType

CardDiscovery (eEHICADMIN)

(1,2,3)

(EntitlementSecurityLevel)

ReadDataSet

(eEHICDataSet)

ReadSecurityLevel

(SecurityLevel)

FunctionalDialog (eEHICDataSet, SecurityLevel)

(APDUCommand)

Execute (APDUCommand)

(APDUResponse)

Loop

(APDUResponse)

FunctionalResponse

End to end communication sequence : card type “1”, “2”, “3” ISO 24727 compliant

Card device

eEHIC

Card App

HCP Application

MS Authentication Proxy


Optional security functionality for future use

Optional security functionality for future use

  • No authentication functionality is mandated

    • Neither on server side (Competent institution)

    • Nor on client side (HCP)

  • eEHIC-Server-communication can be used without any card-based security features

    • Issuers are not mandated to add any part of it

    • Service implementors are not mandated to support these features

  • Authentication functionality can be used

    • If/when security will be needed e.g. for privacy reasons

    • Service related policy decisions possible


Matrix of mandatory components of an eehic system depending from the scenario to be deployed

Matrix of mandatory components of an eEHIC system, depending from the scenario to be deployed


A new cwa

A new CWA


Thank you for your attention

Thank you for your attention 


  • Login