1. The Patient Choice Project Use Case Working Session January 22 nd, 2016

2. Call Logistics If you are not speaking, please keep your phone on mute Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call This meeting is being recorded Feel free to use the “Chat” feature for questions, comments or any items you would like the moderator or participants to know 2

3. Agenda 3 TopicTime Allotted General Announcements5 minutes Patient Choice Use Case Development Confluence Feedback Finalized Assumptions Pre/Post conditions Review Updated User Stories 50 minutes Next Steps/Questions5 minutes

4. General Announcements The Patient Choice project will meet weekly on Fridays @ 11 am ET »The next working group meeting will be on Friday, January 29 th, 2016 at 11 am ET 4

5. 5

6. Proposed Use Case & Functional Requirements Development Timeline WeekTarget DateWorking Session TasksReview and Provide Comments via Confluence (due Thursdays @ 11 am ET) 1&212/28Use Case Process Overview Introduce: In/Out of Scope, Assumptions, Scenarios, User Stories Review: In/Out of Scope, Assumptions, Scenarios, and User Stories 31/8Review: In/Out of Scope, Assumptions, Scenarios, User Stories Review: In/Out of Scope, Assumptions, and User Stories 41/15CANCELLED for HL7Review: In/Out of Scope, Assumptions, and User Stories 51/22Review: Finalized In/Out of Scope, Finalized Assumptions, and User Stories Introduce: Pre/Post Conditions and Base Flow Review: User Stories, Pre/Post Conditions and Base Flow 61/29Review: Finalized User Stories, Finalized Pre/Post Condition and Base Flow. Introduce: Actors and Roles, Activity Diagram Functional Requirements & Sequence Diagram Review: Activity Diagram and Base Flow, and Functional Requirements & Sequence Diagram 72/5Review: Finalized Activity Diagram and Base Flow, and Functional Requirements & Sequence Diagram Introduce: Data Requirements and Risks & Issues Review: Functional Requirements & Sequence Diagram, Data Requirements, and Risks & Issues 82/12Review: Finalized Functional Requirements & Sequence Diagram, Finalized Data Requirements, and Finalized Risks & Issues End to End Review 6

7. Use Case Development Process 7

8. Section Review 1. Discuss and review the following sections: 1.Assumptions 2.Draft User Stories 2. Introduce and review the following sections: 1.Pre/Post Conditions 2.Pull Scenario Base Flows 8 Click the icon to open the Word Document

9. Confluence Feedback “This SSA Push Case can also be used in a more generalized way, for instance re: patients/families requesting letters for school/camp/work; this is a significant amount of administrative work and often has to be completed by provider if sensitive information is involved in order to discuss with patient/determine what should be removed. If the requester submitted a Privacy Consent Directive, work could likely be done by office staff instead” 9

10. Assumptions The requirements of the use case can be implemented in a variety of architectures Patients who are consumers of healthcare services are aware of their ability to complete Consent Directives and do offer such direction to the clinicians and organizations which they engage to provide them healthcare services Electronic systems have the capability to manage and update consent registries/repositories Electronic service information is known All parties in the exchange comply with applicable privacy and security rules »Policy is in place for handling missing or not yet recorded Patient preferences for data sharing »All parties comply with Patient privacy preferences and subsequent handling instructions The use case includes systems where the additionally protected information is integrated with other data within an EHR or other systems that manages Patient health information Disclosures are appropriately updated in the system to be reflected in accounting for disclosures that may be requested by the Patient Appropriate security audit mechanisms are in place Appropriate methods for capturing consent are in place Appropriate patient interfaces are in place 10

11. Pre-Conditions and Post-Conditions Pre Conditions Mechanisms are in place for handling missing or not yet recorded Patient preferences for data sharing Mechanisms are in place for systems having Patient data have to enforce the appropriate legal and policy requirements Mechanisms are in place to comply with Privacy Consent Directives and subsequent handling instructions Post Conditions Receiving system complies with ongoing obligations Sending and receiving systems have recorded the transactions in their security audit records 11

12. Scenario 4: Push Consent Directive and Authorization 12 Data RequesterData Holder Start 1. Data Requester sends Privacy Consent Directive and request for Patient data to provider 2 4. Data Holder decides which information to return and assembles response 2. Data Holder receives Privacy Consent Directive and request for Patient data 6. Data Requester receives response from Data Holder 5. Data Holder sends response to Data Requester End 3. Data Holder checks for its own patient consent directive/ or gets one and then determines whether there’s a match before disclosing

13. Scenario 4: Push Consent Directive and Authorization User Story 1 Context: SSA requires that a patient sign a SSA-827 Authorization to Disclose Information to SSA before an eligibility determination can be processed VA requires that a patient sign a VA FORM 10-5345-SSA before disclosing information to SSA User Story: Alice, who is a disabled veteran, signs the SSA-827 at her local SSA offices where she applies for SSA Disability Insurance Alice also digitally signs the VA FORM 10-5345-SSA online formVA FORM 10-5345-SSA online form SSA sends Alice’s signed SSA-827 along with a request of her health information to the VA The VA compares whether Alice’s permitted disclosures in VA FORM 10-5345-SSA match those in the SSA-827 it received from SSAVA FORM 10-5345-SSA Alice’s preferences in both forms match, so VA sends SSA Alice’s VA health records While generating an electronic copy of Alice’s health information, the VA determines that Alice’s records include information protected under Title 38 Section 7332 such as sickle cell anemia, HIV, or substance abuse. VA marks the record with the Title 38 Section 7334[i] with the required warning to end users that Title 38 Section 7332 protected Title 38 Section 7334information is prohibited from re-disclosure without consent. SSA receives and processes Alice’s SSA Disability Insurance application and complies with the Title 38 Section 7334 prohibition on re-disclosure without consent. 13

14. Scenario 4: Push Consent Directive and Authorization User Story 1 14

15. Scenario 4: Push Consent Directive and Authorization User Story 2 Context: VA automatically opts out from NwHIN exchange any veteran whose records include conditions protected under Title 38 Section 7332, including sickle cell anemia, HIV, and substance abuse disorders. USPS provides an electronic PHR “HealthConnect” to its employees, many of whom, like Alice, are veterans receiving care through the VA. The USPS PHR supports participating individuals with an ability to mark certain records as sensitive, to specify authorized purpose of use, and to name the end user in an organization that receives and individuals health information. User Story: Alice’s records include Title 38 Section 7332 protected information Alice declines to opt in to exchange of any of her records via NwHIN VA makes available and processes Alice’s Patient Right of Access request VA FORM VHA-10-5345aVA FORM VHA-10-5345a Alice is a veteran who works for the US Post Office [USPS], and registers for its employee PHR [USPS HealthConnect].USPS HealthConnect Alice decides to manage the disclosure of her VA information via her USPS HealthConnect PHR 15

16. Scenario 4: Push Consent Directive and Authorization User Story 2 (continued)  USPS HealthConnect PHR pushes Alice’s basic consent directive opting in to her PHR requesting information from the VA per Alice’s Patient Right of Access  VA receives USPS PHR request for Alice’s records along with Alice’s USPS PHR Consent Directive  VA compares the USPS PHR CD with Alice’s VA FORM VHA-10-5345a and determines that her VA and USPS consent directives match  VA pushes Alice’s VA FORM VHA-10-5345a as a consent directive along with Alice’s requested records to end points of her choosing once Alice signs a VA waiver of security and privacy liability.VA FORM VHA-10-5345a 16

17. Scenario 4: Push Consent Directive and Authorization User Story 2 17

18. Scenario 4: Push Consent Directive and Authorization User Story 3 Context Alice has a Medication App and a Kaiser Permanente [KP] Patient Portal, both of which are able to request information from her USPS HealthConnect PHR Alice also has an Authorization Manager [AM] with which to manage authorized information transfers of her USPS HealthConnect information to both her Medication App and her KP Patient Portal Alice’s AM makes access decisions based on Consent Directives pushed to it in the form of claim tokens The USPS HealthConnect PHR has a pub/sub notification capability that allows it to notify authorized subscribers that there is new information in her PHR 18

19. Scenario 4: Push Consent Directive and Authorization User Story 3 (continued) User Story  Alice signs her Medication App basic consent directive authorizing it to collect, access, and use medication and medication allergy information in her USPS HealthConnect PHR, and to disclose only to endpoints of her choosing  Alice signs her KP Patient Portal basic consent directive authorizing it to collect, access, and use medication and medication allergy information in her USPS HealthConnect PHR, and to disclose only as permitted under applicable laws  Alice signs two USPS HealthConnect PHR consent directives  Consent Directive [1] authorizes her PHR to disclose medication and medication allergy information that she has NOT marked sensitive to her Medication App and to KP Patient Portal  Consent Directive [2] authorizes her PHR to disclose medication and medication allergy information that she has marked as sensitive to KP Patient Portal for access only by Dr. Bob, her KP Choice provider 19

20. Scenario 4: Push Consent Directive and Authorization User Story 3 (continued)  Alice introduces her USPS HealthConnect PHR to her AM and authorizes the AM to send authorized information requests to it and to permit the PHR to send update notifications to endpoints of her choosing  Alice introduces her Medication App to her AM and authorizes the AM to handle the Medication App request for medication and medication allergy information in her USPS HealthConnect PHR  Alice introduces her KP Patient Portal to her AM and authorizes the AM to handle KP Patient Portal requests for medication and medication allergy information in her USPS HealthConnect PHR  Alice’s USPS PHR sends update notifications via Alice’s AM to Alice’s Medication App and to her KP Patient Portal  Alice’s Medication App pushes a request for her PHR medication information and claims tokens encapsulating Alice’s Medication App Consent Directive to her AM. Her AM approves the App’s request based on Alice’s AM Consent Directive granting the App access to her PHR medication information. The PHR examines the claims and sees that they match Alice’s PHR Consent Directive 1, so it discloses non-sensitive medication information to the App  Alice’s KP Patient Portal pushes a request for her PHR medication information and claims tokens encapsulating Alice’s KP Patient Portal Consent Directive to her AM. Her AM approves the App’s request based on Alice’s AM Consent Directive granting the App access to her PHR medication information. The PHR examines the claims and sees that they match Alice’s PHR Consent Directive 2, so it discloses both sensitive and non-sensitive medication information to the App 20

21. Scenario 4: Push Consent Directive and Authorization User Story 3 21

22. Scenario 1: Query for Consent Directive (Pull) Provider/ Healthcare Provider Organization Start 1. Determines that Patient data should be requested 2. Sends query for Patient data to the HIO Data Holder/HIO Consent Directive Registry Consent Repository 3. Receives query for Patient data 4. Determines if consent is required to share Patient data 5. Sends query to Consent Directive registry for Privacy Consent Directive location 6. Sends Privacy Consent Directive location 7. Sends query to Privacy Consent Directive Repository 9. Review Privacy Consent Directive to determine the data that may be disclosed. 8. Sends Privacy Consent Directive to HIO 10. Sends Patient data to requesting Provider 11. Receives Patient data End

23. Scenario 1: Query for Consent Directive (Pull) User Story 1: HIE Consent Repository Context HIE maintains a consent repository HIE does not provide data unless request is allowed under recorded consent User Story Patient X presents with abnormal heart rhythm at clinic A Doctor Able recommends taking an exercise stress test from a heart specialist at hospital B Patient X’s consent is (or has been) sent to the HIE Doctor Baker at hospital B requests medical record from the HIE HIE receives request for Patient X record, evaluates request against consent in the repository, and sends the record to Doctor Baker 23

24. Scenario 1: Query for Consent Directive (Pull) User Story 1: HIE Consent Repository Query for consent (3) upon receipt of request for clinical data (2) Consent Repository Clinical IT System Health Information Exchange Clinical IT System HIE Security Domain 1a 4 2 3 1b Other IT System 24

25. Scenario 2: Query for Consent Directive (Pull) User Story 2: HIE / Registry Consent Repository Context HIE and state registry both maintain a consent repository Neither HIE nor state registry provide records unless allowed under consent HIE is integrated within state registry and can forward consent messages User Story Patient Y’s “opt-in” to sharing immunization records from state immunization registry has been sent to the HIE by doctor or patient Patient Y moves within state and visits pediatrician at new location Doctor Charlie requests immunization records from HIE HIE receives request for records, evaluates request against consent in its repository, and sends the request to state registry State registry receives request, evaluates request against consent in its repository, and sends the record to HIE that is then forwarded to Dr. Charlie 25

26. Scenario 2: Query for Consent Directive (Pull) User Story 2: HIE/Registry Consent Repository Query for consent (3, 4) upon receipt of request for clinical data (2a, 2b) Other IT System Clinical IT System 1a 1b 2b 2a Health Information Exchange Consent Repository 1c 3 4 Consent Repository Immunization Registry HIE Security Domain Registry Security Domain 26

27. Scenario 3: Query for Consent Directive (Pull) User Story 3: Hospital Consent Repository Context General Hospital maintains a consent repository Care teams do not provide records unless request is allowed under consent User Story Patient Z receives hip replacement at General Hospital, which is required to follow Comprehensive Care for Joint Replacement (CJR) payment model Patient Z’s consent is (or has been) sent to General Hospital repository Patient Z is discharged to a skilled nursing facility (SNF) Doctor Delta is assigned to follow progress of Patient Z for 90 days post discharge Later, Doctor Delta requests Patient Z’s medical record from the SNF SNF receives request for Patient Z record, evaluates request against consent in General Hospital repository, and sends the record to Doctor Delta 27

28. Scenario 3: Query for Consent Directive (Pull) User Story 3: Hospital Consent Repository Query for consent (3) upon receipt of request for clinical data (2) 28 Clinical IT System Consent Repository Hospital Security Domain 1 Care Team IT System Service Team IT System Care Team IT System 2 3 4

29. Next Steps Review and provide feedback to posted materials: User Stories, Pre/Post Conditions, and Base Flows sections by the following Thursday at 11am ET »http://confluence.siframework.org/display/PATCH/Use+Case+Developmenthttp://confluence.siframework.org/display/PATCH/Use+Case+Development Next meeting is Friday, January 29 th, 2016 at 11 am ET Reminder: All Patient Choice Announcements, Schedules, Project Materials, and Use Case will be posted on the Patient Choice Confluence page »http://confluence.siframework.org/display/PATCH/http://confluence.siframework.org/display/PATCH/ 29

30. Project Contact Information OCPO-ONC LeadJeremy MaxwellJeremy.Maxwell@hhs.gov Project CoordinatorJohnathan Colemanjc@securityrs.com Project ManagerAli KhanAli.Khan@esacinc.com Project SupportTaima GomezTaima.Gomez@esacinc.com Staff SMEKathleen Connorklc@securityrs.com Staff SMEDavid Staggsdrs@securityrs.com 30

31. @ONC_HealthIT@HHSONC Thank you for joining!