privacy architecture considerations n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Privacy Architecture Considerations PowerPoint Presentation
Download Presentation
Privacy Architecture Considerations

Loading in 2 Seconds...

play fullscreen
1 / 23

Privacy Architecture Considerations - PowerPoint PPT Presentation


  • 98 Views
  • Uploaded on

Privacy Architecture Considerations. Opt-In / Opt-Out What Do They Entail How Standards Support Policy. Kathleen Connor Fox Systems Inc. Agenda. Statement of Purpose Brief Introduction to scope the discussion

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

PowerPoint Slideshow about 'Privacy Architecture Considerations' - kesia


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
privacy architecture considerations

Privacy Architecture Considerations

Opt-In / Opt-Out

What Do They Entail

How Standards Support Policy

Kathleen Connor

Fox Systems Inc

agenda
Agenda
  • Statement of Purpose
  • Brief Introduction to scope the discussion
  • Participant introductions and statement of perspective – short summary of your country’s national health information exchange architecture
  • Collect Input
discussion focus
Discussion Focus
  • Consent Policies and Supportive Privacy Architectures – International Perspectives
  • Purpose and Goals
    • Level setting – framework for discourse
      • E.g. Infoway Privacy and Security Architecture structured and aligned policy and technical requirements
    • Survey
      • General structure of health delivery system as context for privacy requirements
      • Collect basic information
      • Validate prepopulated information
      • Would love your participation
    • Input for report
      • Identify Consent Requirements, Feasible Technical Solutions, and Best Practices
    • Initiate ongoing discourse
collection instrument
Collection Instrument

May need to sample range of Nodes within a country from most stringent to least stringent privacy requirements

presentation focus
Presentation Focus
  • Policy, Standards, and Technical Support for Patient consent to collect, use, and disclose PHI
    • Opt-out
      • Total
      • Conditional
    • Opt-in
      • Total
      • Conditional
  • Within Nodes (Df.=Regional Hubs, Sub-networks)
    • Share generally agreed upon privacy policies
  • Among Nodes = National Information Network (e.g., UK Spine, CA EHRi, NL LSP, US NHIN)
  • Role Based Access
  • Standards for electronic consents, shared secrets, privacy policies
opt out
Opt-out
  • Actively refusing to authorize an entity to collect, use, or disclose PHI
  • Actively refusing to authorize a requesting entity to access, use or re-disclose PHI
  • May opt-out at the record or data element level
  • Opt-out may be
    • Total
    • Conditional
opt out1
Opt-out
  • Total Opt-out
    • Off Node
    • Locked/Masked on Node
  • Conditional Opt-out
    • PHI is Masked / Locked
    • Some collection, use, disclosure permitted
      • Pre-determined: By User, Role, Context Based Access
      • Ad-Hoc: By Shared Secret
  • Implied Consent = not Opting out
  • Deemed Consent
    • Public health or legal requirements may override Opt-out
opt out2
Opt-out

Conditional Dissent by Data Element

Non-action = implied consent

Requires active dissent by record / data element

May not have a choice where there is a public health issue

opt in
Opt-in
  • Actively authorizing an entity to collect, use, or disclose PHI
  • Actively authorizing a requesting entity to access, use, or re-disclose PHI
  • May Opt-in at the record or data element level
  • Opt-in may be
    • Total
    • Conditional
opt in1
Opt-in

Conditional Opt-in

    • PHI is Masked / Locked
      • Some collection, use, disclosure permitted
        • Pre-determined: By User, Role, Context Based Access
        • Ad-Hoc: By Shared Secret
  • Implied Dissent = not Opting in
  • Deemed Consent
    • Public health or legal requirements may override Dissent
opt in2
Opt-in

Requires active assent by record / data element

Non-action = dissent

Conditional Assent by Data Element

May not have a choice where there is a public health issue

role based access control
Role Based Access Control

IHE Basic Patient Privacy Consent Profile

slide15

Shared Secret supports Conditional Access that is time limited and may be revoked by the Patient

rbac and masking issues
RBAC and Masking Issues
  • Mapping User Types to Roles
  • Defining Teams
  • Mapping Roles to Authorizations
  • Downstream application of consent parameters
  • Ontology of roles, authorizations, and consent parameters needed for computable interchange
  • Security mechanisms to support time limited, renewable, and revocable shared secret, e.g., scheduled change of key hash with patient ability to revoke key access
nin support for consent
NIN Support for Consent
  • Standards for electronic representation of Node consent policies and patient consents
  • Computable access to Node consent policies
  • Computable patient consent transmitted with associated PHI
  • Standards for computable negotiation of multiple node policies associated with a patient’s PHI
ihe bppc masking use case
IHE BPPC Masking Use Case
  • An Affinity Domain may have jurisdictional or organizational policies that require support for more complex patient privacy consent policies.
  • These privacy policies may require that a patient explicitly consent to disclosure of protected or sensitive health information to specific entities.
  • To implement such policies using the BPPC profile, an Affinity Domain would include sufficiently explicit functional roles as well as contextual and user specific role information to support these policies.
  • For example, in a jurisdiction that requires explicit patient consent to disclose psychotherapy notes, the Affinity Domain would include a sensitivity marker for psychotherapy notes and may only permit access by the functional role

(1) “Named entity”, where the named entity identifier must match the identifier of the named entity in the patient’s associated consent document associated with the patient’s health document;

(2) An “unnamed entity” based on a time limited [i.e., time-bomb] and non-transferrable “shared secret key” supplied to the entity by the patient and authenticated by some algorithm the information in the patient’s associated consent document; or

(3) An emergency provider who submits a “break the glass key” administered by the Affinity Domain that has an appropriate audit trail with documentation of the provider’s reason and context for use per Affinity Domain policy.

ihe bppc use case cont
IHE BPPC Use Case cont.
  • The psychotherapy notes would be submitted to the XDS using the confidentiality code indicating that it is available only to these entities.
  • In addition to document type level sensitivity markers, e.g., psychotherapy notes, an Affinity Domain may support sensitivity markers for types of health information that might be included in documents of many types.
  • There may be sensitivity markers for any document that includes diagnosis, procedure, medication, location, or provider information which the patient believes may indicate that the patient has genetic, substance use, HIV/AIDs, mental health or other conditions, which the patient wishes to mask.
  • Another use for sensitivity markers is for victims of abuse who wish to mask all records containing their demographic information.