1

Privacy Architecture Considerations

Opt-In / Opt-OutWhat Do They EntailHow Standards Support Policy

Kathleen Connor

Fox Systems Inc

2

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

3

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

4

Collection Instrument

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

5

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

6

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

7

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

8

Opt-out Conditional Dissent by

Data Element

Requires active dissent by record /

data element

Non-action = implied consent

May not have a choice where there is a public

health issue

9

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 TotalConditional

10

Opt-inConditional Opt-in

PHI is Masked / Locked Some collection, use, disclosure

permitted Pre-determined: By User, Role,

Context Based AccessAd-Hoc: By Shared Secret

Implied Dissent = not Opting in Deemed Consent

Public health or legal requirements may override Dissent

11

Opt-in

May not have a choice where

there is a public health issue

Conditional Assent by

Data Element

Non-action = dissent

Requires active assent by record / data

element

12

Opt-in / Opt-out Infrastructure

NodeConsent Policy

Registry

Opt Out

Opt In

Patient Registry Patient Consents

NODERLS / Repository

13

Role Based Access Control

IHE Basic Patient Privacy Consent Profile

14

RBAC Support 4 Opt-in / Opt-out

NODEConsent Policy

Registry

Opt Out

Opt In

Patient Registry Patient Consents

NODERLS / Repository

User RegistryIdentifiers, Credentials, Roles, Authorizations

15

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

Opt In

16

Masking Supports Conditional OPT-IN / OPT-OUT

17

RBAC with support for Masking

18

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

19

NODE2NODE via NIN

NODEConsent Policy

Registry

Patient Registry Patient Consents

NODERLS / Repository

User RegistryIdentifiers, Credentials, Roles, Authorizations

NODEConsent Policy

Registry

Patient Registry Patient Consents

NODERLS / Repository

User RegistryIdentifiers, Credentials, Roles, Authorizations

NODEConsent Policy

Registry

Patient Registry Patient Consents

NODERLS / Repository

User RegistryIdentifiers, Credentials, Roles, Authorizations

20

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

21

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.

22

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.

23

HL7 Confidentiality Vocabulary