The Austrian Use Case: eCard

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 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 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 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 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 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 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 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) 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 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 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 Gottfried Heider

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