What IHE Delivers Basic Patient Privacy Consents HIT-Standards – Privacy & Security Workgroup John Moehrke GE Healthcare

2 What do Standards Define? Policy  Driven by business goals  Informed by Risk Assessments  Defines rights and responsibilities  Defines punishment Process  Enforces policy  How people or organizations act  who / what / where / when / how Technology  Enforces policy  How equipment should act  Algorithms and data formats Policy Process Technology

3 Before (2006) One Policy for the XDS Affinity Domain (HIE) Patient doesn’t agree  Don’t publish VIP Patient  Don’t publish Sensitive Data  Don’t publish Research Use  No Access

4 Basic Patient Privacy Consents Human Readable Machine Processable Characteristics of a CDA “Document” Multiple Consent Types and Documents (e.g., HIPAA) Wet Signature Capture (i.e. XDS-SD) Digital Signature Capture Possible (i.e. DSG)  Provider, Witness, Patient or Legal Representative Extensible

5 Document Content & Modes of Exchange Document Exchange Integration Profiles Document Sharing XDS Media Interchange XDM Reliable Interchange XDR Document Content Profiles Consent BPPC Emergency EDR Pre Surgery PPH P Scanned Doc XDS-SD Laboratory XD*-Lab PHR Exchange XPHR Discharge & Referrals XDS-MS Imaging XDS-I Cross-Community Access XCA

6 Value Proposition An XDS Affinity Domain (RHIO, HIE)  Develop a set of privacy policies,  Each policy is given a number (OID)  Implement them with role-based or other access control mechanisms supported by EHR systems. A patient can  Be made aware of the privacy policies.  Have an opportunity to selectively acknowledge the from the policies presented  Have control over access to their healthcare information.

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

8 BPPC supportable Consents Explicit Opt-In is required which enables HIE allowed document use Explicit Opt-Out that would prevent all use of their documents Implicit Opt-In allows for document use Explicit Opt-Out of any document publication Explicit Opt-Out of sharing outside of local event use, but does allowing emergency override Explicit Opt-Out of sharing outside of local event use, and without emergency override Explicit authorization that would allow specific research project Change the consent policy (change from opt-in to opt-out) Allow direct use of the document, but not re-publishing Enable use of document retrieval across communities using XCA Explicit individual policy for opt-in at each clinic Explicit individual policy for opt-in for a PHR choice Explicit Opt-In for a period of time (episodic consent)

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

10 Characteristic of a CDA document PersistenceStewardship Potential for authentication ContextWholeness Human readability A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content.

11 Capturing the Patient Consent act One of the Affinity Domain Consent policies CDA document captures the act of signing  Effective time (Start and Sunset)  templateID – BPPC document  XDS-SD – Capture of wet signature from paper  DSIG – Digital Signature (Patient, Guardian, Clerk,System) XDS Metadata  classCode – BPPC document  eventCodeList – the list of the identifiers of the AF policies  confidentialityCode – could mark this document as sensitive

12 Scanned Document details Privacy Consent details Policy 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 XDS-MS + XDS-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

13 Standards and Profiles Used HL7 CDA Release 2.0 IHE - XDS Scanned Documents  PDF/A - ISO b IHE - Document Digital Signature  XML-Digital Signature, XadES IHE - Cross Enterprise Document Sharing IHE - Cross Enterprise Sharing on Media IHE - Cross Enterprise Reliable Interchange IHE - Cross Community Access

14 Using documents XDS Registry Stored Query Transaction  Consumer may request documents with specific policies  Filtered response XDS Consumer Actor  Informed about confidentialityCodes -- Metadata  Knows the user, patient, setting, intention, urgency, etc.  Enforces Access Controls (RBAC) according to confidentiality codes  No access given to documents marked with unknown confidentiality codes

15 XDR & XDM XDR & XDM Same responsibilities Should include copy of relevant Consents Importer needs to coerce the confidentiality codes Need to recognize that in transit the document set may have been used in ways inconsistent (e.g. Physical Access Controls)

16 Informed by Privacy Policy Standards ISO IS22857 Trans-border Flow of Health Information ISO TS Privilege Management and Access Control (Parts 1, 2, draft 3) ASTM E1986 Standard Guide for Information Access Privileges to Health Information

17 Active Standards Work OASIS  Profile for how to express attributes in cross-organization (SAML, XACML, WS-Trust, WS-Federation, WS-Policy) HL7  Standard for Consent Directive Document  Ontology for Security and Privacy (Permissions, Sensitivity, Healthcare User Roles, etc)  Identified Privacy Policy Reference Catalog (opt-in, opt-out, ++)  SOA model for Privacy/Security Access Control as a Service IHE  White Paper on overall Access Control Model for healthcare  Updates to XUA profile to recognize user attributes such as role, intended- use, authentication level of assurance. ISO  ISO14265: Classification of purposes for processing personal health information

What IHE Delivers Questions?