1. © Gottfried Heider 1 The Austrian Use Case: eCard The eCard Project: giving an electronic card to everyone for accessing personal health record From patients to professionals Governmental patients directory and professional directory

2. © Gottfried Heider 2 eCards 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

3. © Gottfried Heider 3 Communities 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

4. © Gottfried Heider 4 BPPC and requirements from ELGA 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

5. © Gottfried Heider 5 Requirements 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

6. © Gottfried Heider 6 Requirements for BPPC 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

7. © Gottfried Heider 7 Requirements for BPPC 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

8. © Gottfried Heider 8 Requirements for BPPC ( 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)

9. © Gottfried Heider 9 ELGA 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

10. © Gottfried Heider 10 ELGA proposal PEP: Policy Enforcement Point PDP: Policy Decision Point PIP: Policy Information Point PAP: Policy Administration Point Ticket: SAML Token with Pat Id and Role

11. © Gottfried Heider 11 Contacts Feedbacks are welcome! Arbeitsgemeinschaft Elektronische Gesundheitsakte www.arge-elga.at office@arge-elga.at gottfried.heider@ehealthcon.at office@tiani-spirit.com

12. © Gottfried Heider 12 Japanese Hebrew Thank You English Merci French Danke German Grazie Italian Gracias Spanish Obrigado Brazilian Portuguese Arabic Simplified Chinese Traditional Chinese Korean Thai Hindi Tamil go raibh maith agat Gaelic Tak Danish Trugarez Breton Dutch Dank u Czech Dekujeme Vam Dankon Esperanto Tack så mycket Swedish Terima Kasih Malaysian