Privacy Architecture Considerations

1. Privacy Architecture Considerations Opt-In / Opt-Out What Do They Entail How 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 Non-action = implied consent Requires active dissent by record / data element 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 • Total • Conditional

10. 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

11. 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

12. Opt-in / Opt-out Infrastructure

13. Role Based Access Control IHE Basic Patient Privacy Consent Profile

14. RBAC Support 4 Opt-in / Opt-out

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

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

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