© gottfried heider 1 the austrian use case: ecard the ecard project: giving an electronic card to...

© Gottfried Heider 1

The Austrian Use Case: The Austrian Use Case: eCardeCard

The eCard Project: giving an electronic card to everyone for accessing personal health record

From patients to professionals Governmental patients directory and

professional directory


eCardseCards

Is a magnetic card containing an identity of the owner

It is personal and not modifiable It is used for authenticating users and for

retrieving patient’s consent


CommunitiesCommunities

ELGA project is divided in communities that use XDS and XCA for cross-community access

XUA for providing assertions to the user

BPPC for enforcing patient consent


BPPC and requirements from BPPC and requirements from ELGAELGA

Change of Confidentiality Code in the Registry 1 (one) Registry for all Policy Documents

governmental policy repository Authorization for one Doctor and/or Organization

Advanced Patient Privacy Consents BPPC enforce policies at consumer level

This is not exactly following the XACML paradigm

There is the need to “trusted” consumers


Requirements for BPPCRequirements for BPPC

• Change of Confidentiality Code in Registry for one or more special documents

• Reason :• Patient doesn’t like that all doctors should have the view on

all documents independent from the role• Eg:

• Family Doctor shouldn’t see psychiatric documents• Second Oppinion

• How to do ?• The change of this code should be possible without any

replacement of the document – only changing the code• Why this way ?

• If the patient changes the code more than one time the document will be stored very often in the database

• Disadvantage• in the CDA Document the Confidentiality Code is stored =

Different Confidentiality Codes• For Austria it is a must



• All Consent Documents from all Affinity Domains in 1 Registry in a Consent Domain

• Reason :• In Austria we will have approx. 50-60 Affinity Domains and

each Affinity Domain will have 1 (one) Registry• The Consent Document should be unique = should not be

different from one Affinity Domain to the other one• Changing of Consent Document will be done only in one

Affinity Domain• Performance (using eventually caching mechanisms)• Easier to check the Consent Documents in a Document

Consumer and also in a Document Source

• For Austria it is a must



• Consent Documents for 1 (one) Patient (Plan in Austria)• 1 (one) Consent Document without any restrictions

• This Consent Document is only valid for the patient himself• In this case the patient can’t block out himself• This Consent Document will be created from the system

automatically if the patient will be stored the first time in a Master Patient Index

• 1 (one) Consent Document for opt-in / opt-out• The patient should define with time parameter if his

documents can be stored in the Registries or not• Same Rules for Document Source and Document Consumer

• Default will be opt-in• Documents will be stored in Registry• GP’s and hospital organization will have access to the

documents• This Consent Document will be created from the system

automatically if the patient will be stored the first time in a Master Patient Index

• For Austria it is a must


Requirements for BPPCRequirements for BPPC((Advanced Patient Privacy Consents)Advanced Patient Privacy Consents)

• Authorization for one Doctor and/or Organization• Reason :

• Standard BPPC is working with time parameters• In this case the documents are open for all GP’s,

Organizations, Institutes, ..at this time• In Austria we will have legal problems with this (data

protection)• We will have a directory with all Doctors in Austria

• How to do ?• For an outpatient it should be possible to define

which doctor has the rights (dependent from the roles,..) to see his documents at the defined time (will be adjusted from the patient himself via a portal solution)

• Inpatient : this will be done automatically from the system

• For Austria it is a must (Legal Requirement)


ELGA proposalELGA proposal

ELGA proposes to use the XACML and BPPC by enforcing policies at registry (repository) side

Patients and doctors are authenticated using SAMLP for obtaining TWO authentication assertion: one for the patient and one for the doctor (no WS-Federation) XDS queries are performed using XCA carrying the

TWO SAML assertions Using the assertion for the patient, the system

is able to retrieve the patient’s XACML policy Policy is enforced at registry/repository level


ELGA proposalELGA proposal

PEP: Policy Enforcement PointPDP: Policy Decision PointPIP: Policy Information PointPAP: Policy Administration PointTicket: SAML Token with Pat Id and Role


ContactsContacts

Feedbacks are welcome!

Arbeitsgemeinschaft Elektronische Gesundheitsakte

www.arge-elga.at [email protected] [email protected] [email protected]

mailto:[email protected]

mailto:[email protected]


Japanese

Hebrew

Thank YouEnglish

MerciFrench

DankeGerman

GrazieItalian

GraciasSpanish

ObrigadoBrazilian

Portuguese

Arabic

Simplified Chinese

Traditional Chinese

Korean

Thai

Hindi

Tamil

go raibh maith agatGaelic Tak

Danish

TrugarezBreton

DutchDank u

CzechDekujeme Vam

DankonEsperanto

Tack så mycketSwedish

Terima Kasih

Malaysian