the austrian use case ecard n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
The Austrian Use Case: eCard PowerPoint Presentation
Download Presentation
The Austrian Use Case: eCard

Loading in 2 Seconds...

play fullscreen
1 / 12

The Austrian Use Case: eCard - PowerPoint PPT Presentation


  • 74 Views
  • Uploaded on

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. eCards. Is a magnetic card containing an identity of the owner

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

The Austrian Use Case: eCard


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
the austrian use case ecard
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

ecards
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

communities
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

bppc and requirements from elga
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

requirements for bppc
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

requirements for bppc1
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

requirements for bppc2
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

requirements for bppc advanced patient privacy consents
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

elga proposal
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

elga proposal1
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

contacts
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

slide12

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