1. The Patient Choice Project Use Case Working Session February 5 th, 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 Additional Assumptions & Pre/Post Conditions10 minutes Revised Push Scenarios20 minutes Review “PULL” Use Case Scenarios Updated Activity Diagrams New Sequence Diagrams 20 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, February 5 th, 2016 at 11 am ET Introductions 4

5. Phase 1 - Timeline 5 Nov Dec Jan FebMar AprMayJunJulyAugSeptOctNov (Today) Begin Pilot Work Kick Off Pilot Activities Use Case Working Group Kick Off Session Conduct Pilots Needs Assessment Review and development of formal use cases Develop Best Practices IG Draft Basic Choice Standard

6. 6

7. 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 Pre/Post Conditions, PULL Base Flows and Information Interchange Requirements Introduce: PULL Activity Diagrams Review: PULL Base Flows and Information Interchange Requirements, and Activity Diagrams 72/5Review: Finalized PULL Base Flows and Information Interchange Requirements and Activity Diagrams. Introduce: Revised PUSH User Stories and PULL Functional Requirements & Sequence Diagram, Data Requirements and Risks & Issues Review: Revised PUSH User Stories and PULL 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 7

8. Section Review 1. Discuss and review the following sections: »Assumptions »Pre/Post Conditions »PULL User Stories –Base Flows –Information Interchange Requirements –Activity Diagrams –Sequence Diagrams 8 Click the icon to open the Word Document

9. 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 Requester identity is verified and authorized to conduct a query for patient data Appropriate security audit mechanisms are in place Appropriate methods for capturing consent are in place Appropriate patient interfaces are in place 9

10. 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 Mechanisms are in place to ensure the data holder sends the minimum information necessary to a requester in accordance to HIPAA Post Conditions Receiving system complies with ongoing obligations Sending and receiving systems have recorded the transactions in their security audit records 10

11. Push Scenario 1 - Provider pushes Consent Directive to Consent Directive Repository Context »Alice’s PCP participates in the local HIO »Alice consents to her PCP sharing all of her records with other providers for Treatment through the HIO »The HIO accesses patient consent directives through an affiliated Consent Directive Repository User Story Alice recently moved to a new state and finds a new PCP. Her PCP wants to refer her to a Specialist. The PCP tells Alice about the local HIO and explains how the HIO enables her PCP to share her health information quickly and securely with this Specialist versus the alternative of using fax or mailing paper copies. Alice is comfortable with sharing her health information through the HIO for treatment purposes, so she signs the HIO opt-in consent directive. Alice’s PCP pushes Alice’s consent directive to the HIO’s affiliated Consent Directive Repository. Alice’s PCP makes a referral to her Specialist and informs the Specialist that Alice has consented to sharing her health information through the HIO. Alice’s Specialist is now able to request health information from the HIO. [Go to PULL use case.] 11

12. Push Scenario 2 - Provider PUSH to HIO for TPO Context »Alice’s HIO Data Holder allows a patient to opt-out of disclosure. »Alice’s HIPAA Provider is an authorized HIO participant, e.g., has signed the HIO’s DURSA. »Alice’s HIO permits authorized participants to PUSH a patient’s revised HIO consent directive to override the patient’s current Exchange/NwHIN HIO consent directive User Story »Alice signs a consent directive opting out of HIO disclosure of health information it has collected from her participating providers. »Alice begins receiving care from a specialist, who is an authorized HIO participant. »Alice changes her mind and wants her HIO health information disclosed to her specialist. »She signs a HIO opt-in consent directive. »The specialist pushes Alice’s opt-in consent directive with a request for Alice’s health information to the HIO. »The HIO overrides her current opt-out consent directive with Alice’s opt-in consent directive, and sends Alice’s health information to the specialist. 12

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

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

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

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

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

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

19. 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) 19 Clinical IT System Consent Repository Hospital Security Domain 1 Care Team IT System Service Team IT System Care Team IT System 2 3 4

20. Next Steps Review and provide feedback to posted materials: PUSH Activity Diagrams, Functional Requirements & Sequence Diagrams 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, February 12 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/ 20

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

22. @ONC_HealthIT@HHSONC Thank you for joining!