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

2. 204/30/2013 Agenda Administrative issues Review and discussion of user stories Functional requirements in general First draft of functional requirements (Spreadsheet) –Basic flow from IG vs. J-UT –Functional requirements from IG vs. J-UT –System requirements from IG vs. J-UT Detailed functional requirements Questions POA&M first draft of functional requirements Call for new members

3. 304/30/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: +1-650-479-3208 Access code: 662 197 169 URL: https://siframework1.webex.com/siframework1/onstage/g.php?t=a& d=662197169 https://siframework1.webex.com/siframework1/onstage/g.php?t=a& d=662197169

4. 404/30/2013 Review of User Stories 1.Requestor makes request to a provider for patient data on eHealth Exchange 2.Provider receives request from eHealth Exchange for patient information, retrieves PCD from PCD repository and applies, returns status to PCD repository 3.PCD repository receives request for PCD from eHealth Exchange 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

5. Functional Requirements Definition of a Functional Requirement –Address function (what) not implementation (how) –Does not reference other requirements –Contains all information required –Contains only one functional requirement Exercise: how are we changing IG use case 3 predicates in the proposed J-UT user stories? –Illustrates change from original –Allows mapping of existing UC 3 requirements 04/30/2013 5

6. Basic Flow of Use Case (UC) 3 Use Case Development and Functional Requirements for Interoperability (Implementation Guide) Basic Flow –Actor –Role –Event –Inputs –Outputs –Type Mapped to J-UT pilot for coverage test –Consider the Information Interchange type of requirements 04/30/2013 6

7. Functional Requirements of UC 3 Use Case Development and Functional Requirements for Interoperability (Implementation Guide) –Very broadly worded Functional requirements –Initiating System –Action of Initiating System –Information Interchange Requirement Name –Receiving System –Action of Receiving System Mapped to J-UT pilot for coverage test –Consider the Information Interchange type of requirements 04/30/2013 7

8. System Requirements UC 3 Use Case Development and Functional Requirements for Interoperability (Implementation Guide) System requirements –System –System Requirements Mapped to J-UT pilot for coverage test –New systems added Provider/ Healthcare Provider Organization Electronic System Consent Repository Account Holder's Electronic System 04/30/2013 8

9. Basic Flow of J-UT Step 1: review “J-UT Basic Flow” for concurrence Result of mapping to J-UT to UC3 Basic Flow –Use exchange format from previous pilots –Review format for request to consent directive, including specifying patient /account number and consent directive repository –Need to review format for returning consent directive, including specifying patient HIO identifier –Use exchange format from previous pilots, #2 –Need to create format for sending result of decision to consent directive repository, including detail appropriate for patient 04/30/2013 9

10. Basic Flow of J-UT (Pre/Post) Result of mapping to J-UT to UC3 Basic Flow Optional Preconditions –Review format for establishing authentication exchange? –Create format for exchange of Consent Repository Account Holder and HIO identifiers? Optional Post Conditions –Create format for exchange of Consent Repository location and Account Holder identifier to 2nd requestors associated with data exchanged with 1st requester (provenance)? 04/30/2013 10

11. Functional Requirements of J-UT Step 2: review “J-UT Functional Requirements” for concurrence Result of mapping to J-UT to UC3 functional requirements –Need to review format for request to consent directive, including specifying patient /account number and consent directive repository –Need to review format for returning consent directive, including specifying patient HIO identifier –Need to create format for sending result of decision to consent directive repository, including detail appropriate for patient –Need to chose format for sending result of decision to consent repository account holder's electronic system? 04/30/2013 11

12. System Requirements of J-UT 04/30/2013 12 Step 3: review “J-UT System Requirements” for concurrence Result of mapping to J-UT to UC3 system requirements –Do we need to create format for exchange of Consent Repository Account Holder and HIO identifiers? –Need to create format for sending result of decision to consent directive repository, including detail appropriate for patient –Need to choose format for sending result of decision to consent repository account holder's electronic system?

13. Detailed Functional Requirements Step 1: review “J-UT Basic Flow” for concurrence Step 2: review “J-UT Functional Requirements” for concurrence Step 3: review “J-UT System Requirements” for concurrence Step 4: review J-UT detailed functional requirements Assign priority to initial requirements –Requirements from coverage check –Requirements from 04/23/2013 teleconference –Requirements from previous pilots –Additional sources of requirements (future work) E.g. HL7 Implementation Guide for CDA® Release 2: Privacy Consent Directives, Release 1 04/30/2013 13

14. 1404/30/2013 Questions? For example: Can we add new functional requirements? Can we suggest new sources of functional requirements? (no standards yet)

15. 15 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/30/2013

16. 16 Call for Pilot Team Members 04/30/2013 NameRoleOrganization David StaggsParticipantJericho Systems Corporation Michael FieldParticipantUT Austin HIT Lab

17. 1704/30/2013 DS4P References Use Case: http://wiki.siframework.org/Data+Segmentation+for+Privacy+Use+C ases http://wiki.siframework.org/Data+Segmentation+for+Privacy+Use+C ases Implementation Guide: http://wiki.siframework.org/Data+Segmentation+for+Privacy+IG+Co nsensus http://wiki.siframework.org/Data+Segmentation+for+Privacy+IG+Co nsensus Pilots Wiki Page: http://wiki.siframework.org/Data+Segmentation+for+Privacy+RI+and +Pilots+Sub-Workgroup http://wiki.siframework.org/Data+Segmentation+for+Privacy+RI+and +Pilots+Sub-Workgroup

18. 1804/30/2013 Backup Slides

19. 1904/30/2013 Expected Data Flow Patient’s Provider Patient PCD Repository 2 nd Requestor Requestor   B ,  = Clinical data A,B = PCD data = reporting

20. 2004/30/2013 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.

21. 2104/30/2013 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

22. 2204/30/2013 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 Patient 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