The Patient Choice Project Use Case Working Session January 29 th, 2016

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

Agenda 3 TopicTime Allotted General Announcements and Timeline Review5 minutes Patient Choice Use Case Development Confluence Feedback Finalized Pre/Post conditions 10 minutes Review “PULL” Use Case Scenarios Base Flows (13 min) Information Interchange Requirements (13 min) Activity Diagrams (13 min) 40 minutes Next Steps/Questions5 minutes

General Announcements The Patient Choice project will meet weekly on 11 am ET »The next working group meeting will be on Friday, February 5 th, 2016 at 11 am ET Introductions 4

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

Proposed Use Case & Functional Requirements Development Timeline WeekTarget DateWorking Session TasksReview and Provide Comments via Confluence (due 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

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

Confluence Feedback 9 NameCommentDisposition Dan Russler, Consumer Add: The consumer is aware of the rights granted in Federal Regulations to personal copies of all her health records from providers of care with the exceptions as noted in Federal Regulations: Exception 1 Exception 2 Exception 3… We can include as a precondition for all user stories Dan Russler, Consumer I suggest the addition of the simplest use case: 1. Patient requests update to her current copy of her medical record Precondition: Patient has previously signed a consent directive and directly received her medical record (she is unemployed and has no third party agent that holds her person medical records) 1. Patient electronically sends a request for an update to her local medical record with a starting date for the update and and end date of current 2. Receiver electronically returns the recent records to the patient as defined in the scope of the request Post condition Patient now has complete set of medical records locally This is captured through the revised PUSH use cases Dan Russler, Consumer Add as second bullet: Information that must be available at the time of a query for patient data to enable a data source to determine the scope of the data available from the data source that falls within the scope defined in the query for patient data. Note: data source not only has to determine if requesting party is authorized, it needs to assess whether it can technically respond to the request, e.g. is data available; how much data is available; is there any data within the scope of the request that is not authorized to be sent in the response to the requester and, if so, can it be redacted from the response to the requester. Note2: should this bullet be in scope or out of scope? Under Consideration

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 Systems sending Patient data have the capability 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 Receiving system successfully complies with obligations Sending and receiving systems have recorded the transactions in their security audit records 10

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

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 12

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 b Other IT System 13

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 14

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 15

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 16

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

Next Steps Review and provide feedback to posted materials: User Stories, Pre/Post Conditions, Base Flows, and Information Interchange Requirements sections by the following Thursday at 11am ET » Next meeting is Friday, February 5 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 » 18

Project Contact Information OCPO-ONC LeadJeremy Project CoordinatorJohnathan Project ManagerAli Project SupportTaima Staff SMEKathleen Staff SMEDavid 19

Thank you for joining!