“ Jericho / UT Austin Pilot” Privacy with Dynamic Patient Review April 23, 2013 Presented by: David Staggs, JD, CISSP Jericho Systems Corporation

204/23/2013 Agenda Administrative issues User stories Review and discussion of functional requirements Discussion of identifier for patient PCD repository (Optional) Extended data flow for third party requests Questions from the Audience POA&M user stories and requirements documents Call for new members Summary

304/23/2013 Pilot Administrivia This pilot is a community led pilot –Limited support provided by the ONC Apurva Dharia (ESAC) Jeanne Burton (Security Risk Solutions) Melissa Springer (HHS) In conjunction with DS4P bi-weekly return of an All Hands meeting Access to DS4P Wiki, teleconference, and calendar Meeting times: Tuesdays 11AM (ET) –Dial In: Access code: URL: d= d=

404/ User Stories 1.Requestor make request to a provider for patient data on eHealth Connect 2.Provider receives request from eHealth Connect for patient information, retrieves PCD from PCD repository and applies, returns status to PCD repository 3.PCD repository receives request for PCD from eHealth Connect partner, returns PCD, accepts status from AC decision 4.PCD repository receives request for new account from healthcare consumer, possibly involving providers 5.PCD repository allows management of PCD from healthcare consumer 6.Healthcare consumer manages PCD from PCD repository account, views AC status reports

Functional Requirements #1 1. Requestor make request to a provider for patient data on eHealth Connect The Requestor must send the following information to the Provider –Patient identifier in the Provider patient identifier domain –Requestor identifier(s) ( , NPI, name) –Purpose of use for the request 04/

Functional Requirements, 2A Provider receives request from eHealth Connect for patient information, retrieves PCD from PCD repository and applies, returns status to PCD repository The PCD Repository must retrieve the patient consent directive that matches the requestor and the purpose of use. If no match is found, no consent directive should be returned. The PCD repository must respond to the provider only with consent that corresponds to the requestor. If a no consent directive is returned to the provider, the provider may make a default consent decision based on the local policy (opt-in / opt- out) If a consent directive is returned to the provider, the provider must parse and include the consent directive as part of the decision to share the information The response message to the requestor must contain the PCD Repository identifier or URL 04/

Functional Requirements, 2B Provider receives request from eHealth Connect for patient information, retrieves PCD from PCD repository and applies, returns status to PCD repository If a PCD Repository returned a consent directive in step 3, the provider MUST send an audit log to the PCD Repository for every document requested. This audit log must contain –The patient identifier for the provider –The patient identifier for the requestor –The purpose of use for the request –The resource requested –The provider community id –The requestor community id –The requestor identifier ( , NPI, name) –The decision (permit / deny) –The basis for the decision (jurisdictional policy, patient consent, etc.) 04/

Functional Requirements 3 PCD repository receives request for PCD from eHealth Connect partner, returns PCD, accepts status from AC decision The PCD Repository must index the audit logs received so that patients may view, filter, and search on the access attempts. 04/

Functional Requirements, 4 PCD repository receives request for new account from healthcare consumer, possibly involving providers The PCD Repository must maintain account credentials for the patient The PCD Repository must create a unique identifier for the patient that may be used by providers to request the consent directive. The PCD Repository must maintain a mapping of patient identifiers when a patient strongly authenticates with a provider. (stretch) 04/

Functional Requirements, 5 & 6 PCD repository allows management of PCD from healthcare consumer Healthcare consumer manages PCD from PCD repository account, views AC status reports The PCD must support creating, updating, and deleting consents The PCD must support Opt In/Opt Out/Opt In With Restrictions/Opt- Out with Exceptions 04/

1104/ Data Flow Expected Patient’s Provider Patient PCD Repository 2 nd Requestor Requestor   B ,  = Clinical data A,B = PCD data = reporting

1204/ Scope of the Pilot 1. Define the exchange of HL7 CDA-compliant PCD between a PCD repository and a provider evaluating that includes a report on the outcome of the request back to the healthcare consumer. 2. Additional goal: use of identifiers that can uniquely identify the healthcare consumer and PCD repository used to report the outcome of the request back to the healthcare consumer by healthcare consumer’s provider and subsequent EHR custodians. 3. Stretch goal: use of the PCD repository as a proxy allowing direct authentication by the healthcare consumer to the provider, subsequently reducing correlation errors.

1304/ Secondary Goals of the Pilot Exchange and enforce privacy metadata to ensure proper policy- based disclosure and redisclosure of PHI Accept and display reports from information owners on access control decisions for requests for the patient’s PHI Create a token passing scheme that facilitates secondary use reporting Demonstrate dynamic reporting of access to a patient’s PHI and their ability to change their PCD using their PCD central repository

1404/ Available Roles Holder of PHI that is participating on the eHealth Exchange –Accepts eHealth Exchange compliant request –Retrieves PCD and reports result of request –Synthetic Patent Data is Available Requester of PHI that is participating on the eHealth Exchange –Makes eHealth Exchange compliant request Repository holding subject’s Patient Consent Directive (PCD) –Transmits PCD to trusted eHealth Exchange requesters –Accepts policy created by subject of shared PHI –Passes HL7-compliant PCD –Displays result of the request transmitted from holder of PHI

1504/ Questions? For example: Can we add a new user story? When do we know to stop collecting functional requirements?

16 Plan of Action Upon agreement of the participants the POA is Identify the elements available from previous DS4P pilots Scope level of effort, decide on extended scenario Determine first draft of functional requirements Review standards available for returning information on requests Determine gaps or extensions required in standards Create XDS.b repository holding PCD Stand up information holders and requestors Identify remaining pieces Document and update IG with results of our experience 04/232013

17 Call for Pilot Team Members 04/ NameRoleOrganization David StaggsParticipantJericho Systems Corporation Michael FieldParticipantUT Austin HIT Lab

1804/ DS4P References Use Case: ases ases Implementation Guide: nsensus nsensus Pilots Wiki Page: +Pilots+Sub-Workgroup +Pilots+Sub-Workgroup