1 / 22

Adaptive Credentials for Health Data Access

Dynamic system for granting access to health data using digital certificates issued based on a user's access history. Identity and attribute certificates allow for secure and automated authorization decisions.

doris-briggs
Télécharger la présentation

Adaptive Credentials for Health Data Access

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE5810: Intro to Biomedical Informatics Dynamically Generated Adaptive Credentials for Health Information Exchange EugeneSanzi

  2. Problem • Many stakeholders want easy access to new systems • Physicians need to access patient data, no matter where it may be • Researchers want access to de-identified data repositories • Data may be needed quickly • Emergency medical situations leave little time to gain proper authorization • Systems today still use outdated username/password techniques • Incorrect assumption that physicians have time and ability to register with these systems

  3. Requirements • Need a way for physicians identify themselves to any system • Users possess an electronic ID that they can present for authentication • Provide a method for verifying that presented credentials are legitimate • Allow systems to automatically allow or deny different levels of access based on the presented credentials

  4. SolutionOverview • A physician gains access to different systems over the course of a career • Ex. - Access to their local hospital's data • Access may happen under different roles • Use the physician's system access history as a set of credentials • Each system grants a certificate if access is allowed • Physicians can collect these certificates into a digital wallet and present them as credentials • Systems can see which other systems have granted access

  5. Certificates • Identity certificates are used to establish a user's identity • Public key cryptography is used to ensure that you are communicating with the certificate's owner • Certificates are issued by Certificate Authorities (CAs) • Certificate authorities establish user's identity by other means before issuing a certificate • Ex. Driver's license, SSN • You trust any valid certificate issued by a certificate authority that you trust • Certificate authorities sign the certificates they issue • The user inspects the signature, a valid signature proves it was issued by the certificate authority

  6. Certificates

  7. AttributeCertificates • A specialized certificate that stores attributes in a key-value pair format • Attribute certificates are signed by an attribute authority rather than a certificate authority • Attribute certificates are connected to an identity certificate • An identity certificate may be tied to multiple attribute certificates • We will use this ability to store information related to user access • Save information on user role assigned by the system

  8. DIRECTProject • Has the concept of a HISP (Health Information Service Provider) • Concept encapsulates systems needed for health exchange • HISPs must maintain their domain and a list of Trusted Anchors • Trusted Anchors are like root certificates • If one certificate in a certificate chain during the certificate validation process is found to be a trusted anchor, the leaf certificate is valid

  9. DIRECT Project

  10. OIDs • HL7 OIDs are prefixed with the code 2.16.840.1.113883 • There are 3 root branches • The 2 indicates that the root of this branch is managed by JOINT-ISO-ITU-T • Each number represents another branch in a hierarchy • HL7 controls all the children of this code • New OIDs can be generated by registering them with a node's registration authority • HL7 provides a form where new OIDs can be submitted and become part of the HL7 OID standard • A record of the user who submitted the OID is kept on record

  11. Gaining Access • When John Smith wants to obtain access to a new system, he will: • Create a secure connection to the system • Decide which credentials he will send to gain access • Send the relevant identity and attribute certificates along with the request • If access is granted, John Smith will generate a new public/private key pair and receive a new identity and attribute certificate issued by the system's certificate and attribute authority • The system may choose to use a session-scoped Rule Certificate to define John's security policy

  12. DefiningAnAccessPolicy • Each system defines a security policy that specifies constraints based on: • The user role • The type of data being accessed • Valid certificates presented • Provide a mapping from HL7 defined roles to the data that the system guards • Mappings for remote, automatically authenticated users may be different from the mappings given to local users

  13. Example • John Smith wants to access research data on diabetes management from Day Kimball Hospital • He does not have any kind of affiliation with Day Kimball Hospital • He does have his digital wallet of certificates proving his active involvement in the field of medical research

  14. John Smith's Wallet

  15. Choose Relevant Credentials

  16. Send Request With Credentials

  17. Check Security Policy

  18. Generate Certificates

  19. John Smith's New Wallet

  20. JohnSmith'sNewWallet • John Smith adds the identity and attribute certificates issued to him to his digital wallet • He can now use the certificate issued to him by Day Kimball hospital to gain access to other new systems • Day Kimball Hospital can now identify him with his new identity certificate • John Smith could also make requests for Physician role access using his attribute certificates that name him a physician and the certificates given to him by Day Kimball Hospital

  21. FutureWork • Increase the granularity of security policies • Providers may want to allow/deny access based on location as in Access Control based on Attribute Certificates for Medical Intranet Applications • If a physician is requesting information for a specific patient they have already treated it may help the decision process • May require extension to attribute certificates • Security based on Access Time or Count • Someone who only accessed research data once 20 years ago for a school project should not have automatic access to research data now • Differentiate between certificates issued by an employer and certificates issued in an automatic fashion

  22. FutureWork • Increase efficiency • Validating long certificate chains is a time consuming process • Updates to saved attributes would result in needing to have the Attribute Authority resign attribute certificates • How can a physician regain proper credentials if a CA is compromised? • How to handle local practices which may not have a separation between certificate administration and the medical providers using certificates • Need a method for constraining what local CAs can do

More Related