The Patient Choice Project Use Case Working Session January 8 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 Announcements5 minutes Patient Choice Use Case Development Use Case Timeline In/Out of Scope, Assumption, Scenarios Introduction to User Stories 50 minutes Next Steps/Questions5 minutes General Announcements The Patient Choice project will meet weekly on 11 am ET The working group meeting on Friday, January 15 th, 2016 has been CANCELLED due to HL7 The next working group meeting will be on Friday, January 22 nd, 2016 at 11 am ET 4 5 General Use Case Outline Preface and Introduction 2.0 Initiative Overview 2.1 Initiative Challenge Statement 3.0 Use Case Scope 3.1 Background 3.2 In Scope 3.3 Out of Scope 3.4 Communities of Interest 4.0 Value Statement 5.0 Use Case Assumptions 6.0 Pre-Conditions 7.0 Post Conditions 8.0 Actors and Roles 9.0 Use Case Diagram 10.0 Scenario: Generic Provider Workflow 10.1 User Story 1, 2, x, 10.2 Activity Diagram o Base Flow o Alternate Flow 10.3 Functional Requirements o Information Interchange Requirements o System Requirements 10.4 Sequence Diagram 11.0 Risks, Issues and Obstacles 12.0 Dataset Requirements Appendices Related Use Cases Previous Work Efforts References 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, Actors and Roles, Activity Diagram and Base Flow Review: User Stories, Pre/Post Conditions, Actors and Roles, Activity Diagram and Base Flow 61/29Review: Finalized User Stories, Finalized Pre/Post Conditions, Finalized Actors and Roles, Activity Diagram and Base Flow. Introduce: 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 7 Use Case Development Process 8 Section Review 1. Discuss and review the following sections: 1.Scope Items 2.Assumptions 3.Activity Diagram 2. Introduce and review the following sections: 1.Draft User Stories 9 Click the icon to open the Word Document Phase 1: In-Scope Semantic understanding of a Basic Choice consent decision and the corresponding information that comprises a privacy consent directive Information that must be available a the time of a query for patient data to enable a data source to determine if the requester is authorized to receive a response Demonstrate the use of computable consent to enable privacy policy implementation and information access control decisions 10 Phase 1: Out of Scope Methods for Capturing Consent Patient Interfaces Mechanisms for managing a consent directive Policies surrounding information that has already been shared when a patient changes their privacy consent directive to Do not share Mechanisms to update privacy consent directives Maintenance and updating of consent registries Maintenance and updating of consent repositories 11 Use Case 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 Federal privacy and security rules 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 Policy is in place for handling missing or not yet recorded Patient preferences for data sharing All parties commit to having the capability to comply with Patient privacy preferences and subsequent handling instructions. is in place for handling information that has already been shared when a patient changes their privacy consent directive to Do not share 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 Consent Directives are based on the most current and up to date Patient privacy preferences 12 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 Xs 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 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 15 Scenario 1: 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 Ys 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 Scenario 1: 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 Scenario 1: 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 Zs 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 Zs 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 Scenario 1: 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 Scenario 2: Push Consent Directive and Authorization 20 Data RequesterData Holder Start 1. Data Requester sends Privacy Consent Directive and request for Patient data to provider 2 3. Data Holder decides which information to return and assembles response. 2. Data Holder receives Privacy Consent Directive and request for Patient data 5. Data Requester receives response from Data Holder 4. Data Holder sends response to Data Requester End Scenario 2: Push Consent Directive and Authorization User Story 1 SSA receives an electronic and hard-copy of Alices SSA-827 Authorization to Disclose Information to SSA. SSA is able to validate Alices identify because she authenticated to her MyHealtheVet account when she filled out, digitally signed, and submitted her electronic SSA-827. SSA is also in receipt of her hard-copy version of the same SSA-827 form. SSA attaches her Consent Directive to SSAs request for all of her VHA records. VHA receives SSAs request for all of Alices records along with her electronic Consent Directive via NwHIN. VHA processes this request through the enterprise VHA access control system, which is connected to all points of external protected health information disclosure. VHAs access control system determines that VHA is a trusted NwHIN partner. VHA validates that Alice is the author the SSA-827 Form by checking her digital signature, and releases the requested information to SSA via NwHIN. 21 Next Steps Review and provide feedback to posted materials: User Stories, In/Out of Scope, Assumptions, and Scenarios 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 22 nd, 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/ 22 Project Contact Information OCPO-ONC LeadJeremy Project CoordinatorJohnathan Project ManagerAli Project SupportTaima Staff SMEKathleen Staff SMEDavid 23 Thank you for joining!