1. Consumer Privacy using HITSP TP30 John Moehrke – GE Healthcare Co-Chair HITSP Security/Privacy/Infrastructure Co-Chair HL7 Security Workgroup Member IHE IT Infrastructure Committee Blog – http://healthcareSecPrivacy.blogspot.comhttp://healthcareSecPrivacy.blogspot.com October 20, 2010

2. Focus Electronic standards for privacy, not so much security Interoperability between systems, not so much within internal systems Applicability to EHRs, PHRs and HIEs Capabilities to capture, exchange and execute privacy consents, authorizations, directives and preferences 2

3. Basic Concepts What is Privacy (of health information)? – An individual's (or organization's) right to determine whether, what, when, by whom and for what purpose their personal health information is collected, accessed, used or disclosed What is Security (of health information)? – A defined set of administrative, physical and technical actions used or taken to protect the confidentiality, availability and integrity of health information Source: HITSP Vocabulary – modified and expanded from 45 CFR 164.304

4. Privacy of Health Information – Important Underlying Realities Medical records among the most sensitive information about a person Health care is an information-driven field Information is much more complex than other industries (amount, type, frequency) Once exposed, can’t be revoked Health information is central to the doctor-patient relationship Privacy and security of health information are central to the doctor-patient relationship

5. Health care is a complex system, when it comes to health information – Many actors (patient, provider, health plan, employer, government, public health, researchers, vendor, etc) – Various types of information (demographic, clinical, financial) – Many processes related to health information (collection, creation, maintenance, access, use, disclosure) – Different purposes (treatment, payment, operations, public health, research, judicial, legal, etc) – Many places where health information reside – Lack of common identifiers and other standards Privacy of Health Information – Important Underlying Realities

6. Inter-jurisdictional Portability – Consumer privacy consent laws and requirements, and consumer privacy desires and directives in one jurisdiction may not be legally applicable/enforceable in another jurisdiction An entity operating in one jurisdiction uses and discloses health information based on its own policies and procedures, created to meet consent requirements under that jurisdiction When information is disclosed to a different entity in another jurisdiction, the receiving entity applies its own policies and procedures to the received data, which where created to meet consent requirements under the receiving entity’s jurisdiction Privacy of Health Information – Portability Issues

7. Cross-validation and verification of conflicting consents – What is the most recent/latest consent from a patient? – Does that override other consents for specific data, specific purpose? – Where can I find the various consents issued by a consumer to perform cross-validation and verification? Privacy of Health Information – Cross-validation Issue

8. A Consent Directive is a record of a consumer’s privacy policy, in accordance with governing jurisdictional and organization privacy policies, that grant or withhold consent: – To one or more identified entities in a defined role – To perform one or more operations (e.g., collect, access, use, disclose, amend, or delete) – On an instance or type of health information – For a general or specific purpose, such as treatment, payment, operations, research, public health, quality measures, health status evaluation by third parties, or marketing – Under certain conditions (e.g., when unconscious) – For specified time period (e.g. effective and expiration dates) – In certain context (e.g., in an emergency) Electronic Standards for Consumer Consent – What are Privacy Consent Directives?

9. 9  Most consumer privacy consent/authorization still conducted via paper forms  General consumer privacy consent offered at initial point of care/enrollment (when required)  Additional patient consent/authorization used for specific types of health information, specific disclosure purposes (when required)  No standard paper consent forms within a jurisdiction (national, state)  Each organization/program has its own forms  Some States beginning to establish a standard ‘reference’ form (i.e. MN) Consent/Authorization – Current Practices

10. 10  EHRs  Specific screens and ‘forms’ used within the EHR to capture various consumer consents  Informed consent (for treatment)  Release of Information Authorization (i.e., payment purposes)  Authorization for other disclosures, when required  Some data ‘flagged’ by EHR due to sensitivity  Defined by organization and customized by vendor  Based on specific laws that afford special protections to certain data  Consumer signature captured via digital pad or through consumer acknowledgment (“…click here to accept…”) Consent/Authorization – Current Practices

11. 11  PHRs (vendor-provided)  Consumer controls all information added to the PHR, accessed or disclosed  “EULA” or “Agree to Terms” screen  Additional authorizations used for specific disclosures  HIEs  Opt-in / Opt-out approach  General Opt-out  General Opt-in (all-or-nothing)  Opt-in with Specific Restrictions Consent/Authorization – Current Practices

12. 12 Offer consumers and the health care industry an interoperable, standard-based electronic mechanism to collect/capture, maintain, report/ transfer/exchange and act/execute consumer consent directives and preferences, in a manner that allow users to meet different types of jurisdictional requirements and organizational policies Electronic Standards for Consumer Consent A New Paradigm

13. 13  Consumer-friendly mechanism  To allow consumer to manage their consent preferences and directives electronically in a simple, reliable, secure, efficient and effective manner  Scalable  Allow to go from General (overall opt-in/opt-out) to Granular (specific data, specific people, specific people)  Codifiable  Uses standard codes to express consent directives  Machine-readable/Machine-actionable  Does not require human intervention to process  Allow systems to operationalize access, use and disclosure controls Electronic Standards for Consumer Consent – Key Characteristics

14. 14  Portable/Transferable/Interoperable  Uses interoperable standards that allow it to be electronically ported/transferred between organizations and across jurisdictions  Flexible/Adaptable  Supports different jurisdictional requirements  Features can be ‘turn-on’ or ‘turn-off’ based on differing levels of requirements and organizational policies  Valid/Verifiable/Auditable  Supports digital signature, non-repudiation, audit controls  Unambiguous/Completeness  Conflicts between directives can be identified and resolved Electronic Standards for Consumer Consent – Key Characteristics

15. 15 From Privacy Consent to Comprehensive Consent Management Consent/Authorization Consumer Privacy Preferences Consent Directives Access Control Policies Consent Management System

16. Interoperability – The Focus of HITSP Internal Security Policies, Procedures and Practices Secure System Architecture Internal Security Policies, Procedures and Practices Secure System Architecture Inter-organizational Exchange Security Privacy Infrastructure Intra-organizational Security, Privacy, Infrastructure Intra-organizational Security, Privacy, Infrastructure

17. 17  Integrating the Healthcare Enterprise, a world-wide consortium of vendors and health care organizations (www.ihe.net)  Developed the BPPC Profile = Basic Patient Privacy Consent  Most widely recognized standard ‘profile’ for capturing and sharing privacy preferences within an affinity domain (i.e., an HIE)  Provides the mechanism to:  Record the patient privacy consents  Mark documents with the patient privacy consent  Enforce the privacy consent appropriate to the use  Leverages the same Transport mechanism as the Clinical Documents IHE

18. 18  BPPC uses Object Identifiers (OIDs) to codify the privacy preferences within an affinity domain (i.e., HIE)  The affinity domain (exchange) defines the consent policies and each is identified with an OID  Organizations within the affinity domain offer the consent policy options to consumers  Consumers makes privacy preferences based on consent policies offered  Consumer Consent Acknowledgement is captured in a CDA document (the BPPC profile) and published like any other HIE document IHE - How BPPC works:

19. 19  Opt-In to clinical use  Opt-Out of sharing outside of local event use, allowing emergency override  Opt-Out of sharing outside of local event use, without emergency override  Specific document is marked as available in emergency situations  Additionally allow specific research project  Additionally allow specific documents to be used for specific research projects  Limit access to functional roles (eg: healthcare) (direct care) providers  Limit access to structural roles (eg: organizational) (radiologist, cardiologist)  Allow direct use of the document, but not allowed to re-publish  when the document is published on media  when the document is published point-to-point  when the document is retrieved across communities  individual policy for opt-in at each clinic  individual policy for opt-in for a PHR choice (choosing from all possible PHRs) IHE - Types of Policies Supported

20. Written Policy Example 20 The patient agrees to share their healthcare data to be accessed only by doctors wearing a chicken costume.

21. Basic Patient Privacy Consents Human Readable Machine Processable Supports standards-based Access Controls Multiple Consent Types and Documents (e.g., HIPAA) – Opt-in or Opt-out – Implicit or Explicit – Time Limited Wet Signature Capture (i.e. XDS-SD) Digital Signature Capture Possible (i.e. DSG) – Provider, Witness, Patient or Legal Representative Extensible

22. Scanned Document details Privacy Consent details Policy 9.8.7.6.5.4.3.2.1 S S t t r r u u c c t t u u r r e e d d C C o o n n t t e e n n t t w w i i t t h h c c o o d d e e d d s s e e c c t t i i o o n n s s : : Structured and Coded CDA Header Time of Service, etc. Base64 encoded BPPC + XDS-SD Patient, Author, Authenticator, Institution, XDS Metadata: Consent Document Digital Signature IHE-DSG – Digital Signature Signature value Pointer to Consent document Consent document

23. 23  All Clinical Documents are Published with Metadata sensitivity classification (aka ConfidentialityCode)  All Users identified with Roles  Access Permissions  Users can be clinical, financial, operational, research, patient, guardian, etc (See IHE XUA)  When a User requests access to a resource an Access Control decision  YES/NO  User Rights, Physical Location  Purpose of Use,  Data sensitivity classification  Current Consent/Authorizations Enforcing Policy (aka HITSP TP20)

24. 24 Access Control: UML Activity Diagram

25. Patient ID Manager Document Registry Document Repository HIE Complex Patient Privacy Policy Enforcement PCP gets HIV History PCP Security Domain 1 3. Submits psychiatrist Referral 4. Mental Specialist Security Domain 2 Specialist gets all History 5. Specialist submits restricted Mental Eval 6. PCP does not get restricted Mental Eval 7. Emergency care team gets all doc Hospital Emergency Security Domain 4 9. Dietician Specialist Security Domain 3 8. Dietician does not get HIV results or Mental Eval Lab Test Security Domain 1 Lab publishes HIV Results 2. 1. Patient Security Domain 1 Patient HIE Consent Opt-in

26. HHS Whitepaper on Consent (March 2010) No consent. Health information of patients is automatically included—patients cannot opt out; Opt-out. Default is for health information of patients to be included automatically, but the patient can opt out completely; Opt-out with exceptions. Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included; Opt-in. Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out; and Opt-in with restrictions. Default is that no patient health information is made available, but the patient may allow a subset of select data to be included. 26