1. The Patient Choice Project Use Case Development Introduction

2. Objectives The purpose of this material is to provide committed contributors with an introduction to the use case development process and to become familiar with the use case template prior to our next working session Additionally, initial strawman material is included for committed contributors to review and provide any feedback via the Patient Choice Confluence Site »http://confluence.siframework.org/display/PATCH/Use+Case+Developmenthttp://confluence.siframework.org/display/PATCH/Use+Case+Development 2

3. ACTION ITEM: Schedule Next Working Group Meeting If you have not already, please fill out the doodle poll with your availability for the next working group meeting during the week of January 4 th - January 8 th, 2016doodle poll »http://doodle.com/poll/3rmzr7gkmysh772xhttp://doodle.com/poll/3rmzr7gkmysh772x 3

4. Table of Contents 4 Introduction to the Use Case Process SectionSlide Number Use Case Development Objectives5 Use Case Development Approach6-7 General Use Case Outline8 Review of Use Case Sections9-17 Use Case Working Materials SectionSlide Number Proposed Use Case & Functional Requirements Development Timeline 19 Use Case Development Process20 Use Case Assumptions21 Phase 1: In-Scope22 Phase 1: Out-of-Scope23 Scenario 124-25 Scenario 226-29 Next Steps30

5. Use Case Development Objectives Engage Stakeholders as Committed Members, Invite Experts, or Interested Parties in the creation of a Use Case Identify Scenarios and User Stories that address real-world problems Keep it simple Focus on the business and functional requirements: Focus on “what” the requirements should be rather than “how” Create a finalized Use Case that demonstrates value and supports the proposed goals and success criteria for the Initiative Publish a finalized Use Case that contains necessary content, supported by artifacts, to support pilots Establish Use Case and supporting artifacts in a reusable fashion to support future health information interchange Initiatives 5

6. Use Case Development Approach 1.Incorporate Challenge Statement, Value Statement and Scope Statement from Initial Documents » Foster discussion with the workgroup providing introductory context 2.Develop the Scenarios » Organizes the Use Case into logical components 3.Develop the User Stories » Provide real life application examples of the improved technology that the Use Case is meant to support 4.Define the Actors » Derived from User Stories 5.Identify the Assumptions, Pre-Conditions and Post Conditions » Lay the foundation for creating the Functional and Dataset Requirements » Act as inputs for the standards harmonization activities 6.Develop the Diagrams »Use Case, Context, Activity, Sequence diagrams represent the interaction between systems 6

7. Use Case Development Approach (cont’d) 7.Develop the Functional Requirements »Identify the capabilities a system in a role must have in order to enable interoperable exchange of the healthcare data of interest »Provide a detailed breakdown of the requirements in terms of the intended functional behaviors of the application »Includes System Requirements and Information Interchange Requirements 8.Develop Dataset Requirements »A table representing the data elements and data element sets that will be available within the message or document. 9.Finalize Issues, Risks and Obstacles »Compiled throughout the Use Case development process 10.Achieve consensus on the Use Case Package 7

8. General Use Case Outline 8 1.0 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 10.2.1 Base Flow o 10.2.2 Alternate Flow – 10.3 Functional Requirements o 10.3.1 Information Interchange Requirements o 10.3.2 System Requirements – 10.4 Sequence Diagram 11.0 Risks, Issues and Obstacles 12.0 Dataset Requirements Appendices – Related Use Cases – Previous Work Efforts – References

9. Review of Key Use Case Sections Assumptions, Pre-Conditions, Post-Conditions Assumptions »Outlines what needs to be in place to meet or realize Use Case requirements »Functional in nature and state broad overarching concepts related to the Initiative »Serve as a starting point for subsequent harmonization activities Pre Conditions »Describes the state of the system, from a technical perspective, that must be true before an operation, process, activity or task can be executed »Lists what needs to be in place before executing information exchange as described by Functional Requirements and Dataset requirements Post Conditions »Describes the state of the system, from a technical perspective, that will result after the execution of the operation, process activity or task 9

10. Review of Key Use Case Sections Defining the Actors Outlines business actors who are participants in information exchange requirements for each scenario »A business actor is a person or organization that directly participates in a scenario Business actor must use a system to perform functions and participate in the information interchange »The system or system actor has roles (send, receive, publish, subscribe or in some cases display) and actions which involve exchanging content. 10 Example ActorSystemRole PCPEHR SystemSender SpecialistEHR SystemReceiver PatientPHR SystemReceiver

11. Review of Key Use Case Sections Use Case Context Diagram Conceptually represents business actors interacting with Use Case and User Stories Provides a pictorial representation of environment where exchange takes place Characterizes types of interactions that an actor has with a specific system Shows the association and interaction between business actors and Use Case Provides an overview of actors (users or external systems) and interactions between them 11 DRAFT EXAMPLE

12. Review of Key Use Case Sections Scenarios A comprehensive description of actors, interactions, activities, and requirements associated with information exchange Pertain to supporting the health information exchange and describing key flows Scenarios are supplemented by User Stories Example: Specialist requests a patient’s Clinical Care Summary from Primary Care Provider (PCP) 12 Scenario 1 User Story 1 User Story 2 Scenario 2 User Story 1User Story 2

13. Review of Key Use Case Sections User Story Describes real world application as an example or instantiation of a Scenario Summarizes interaction between Use Case actors, and specifies what information is exchanged from a contextual perspective Interactions are further described in subsequent sections »Historically, user stories have been utilized to provide clinical context Example Scenario (from previous slide): Specialist requests a patient’s Clinical Care Summary from Primary Care Provider (PCP) Example User Story: A Specialist receives a referral and requires more information to treat the patient properly at the point of care. Using an EHR System, the Specialist sends a request to the PCP for the patient’s Clinical Care Summary. The PCP successfully receives the requests, understands the requests, and sends the patient’s Clinical Care Summary back to the Specialist via the EHR System. The Specialist successfully receives the patient information, understands it, and makes an informed decision that can provide better quality of care to the patient. 13

14. Review of Key Use Case Sections Activity Diagram A form of a state transition diagram in which all or most of the states are activity states or action states Illustrates Use Case flows graphically, and represents flow of events and information between actors »Displays the main events/actions required for data exchange and the role of each system in supporting the change 14

15. Review of Key Use Case Sections Functional Requirements Identify capabilities a system in a role must have to enable interoperable exchange of healthcare data Provide a detailed breakdown of the requirements in terms of the intended functional behaviors of the application Functional Requirements include: Information Interchange Requirements define the system’s name and role Specify actions associated with actual transport of content from the sending system to the receiving system System Requirements include requirements internal to the system necessary to participate successfully in the transaction Detail workflow that is essential to the Use Case 15

16. Review of Key Use Case Sections Sequence Diagram Show interactions between objects in sequential order of occurrence »Communicates how exchange works by displaying how different components interact »Primary use of diagram is the transition from requirements expressed as use cases to more formal level of refinement NOTE: Horizontal lines identify specific activity between systems 16

17. Review of Key Use Case Sections Dataset Requirements & Issues, Risks & Obstacles Dataset Requirements Include data elements and data element sets within message or document Each data element included is necessary for some aspect of Use Case; however, requirements do not specify exactly how they may be used together All data element sets may contain multiple data elements unless otherwise stated Identification of data elements forms the foundation for harmonization activities Data elements identified in Use Case set constrain the contents of documents and messages Issues Risks and Obstacles Concerns that might interfere with meeting requirements of Use Case 17

18. 18

19. Proposed Use Case & Functional Requirements Development Timeline WeekTarget Date (Week of) Working Session TasksReview and Provide Comments via Confluence (due TBD) 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/4Review: In/Out of Scope, Assumptions, Scenarios, User Stories Introduce: Pre/Post Conditions Review: In/Out of Scope, Assumptions, and User Stories, Pre/Post Conditions 41/11Review: Finalize User Stories, Pre/Post Conditions Introduce: Actor and Roles, Activity Diagram and Base Flow Review: Pre/Post Conditions, Actors and Roles, Activity Diagram and Base Flow 51/18Review: Actors and Roles, Activity Diagram and Base Flow Introduce: Functional Requirements & Sequence Diagram Review: Functional Requirements, Sequence Diagram 61/25Review: Functional Requirements, Sequence Diagram Introduce: Data Requirements and Risks & Issues Review:, Data Requirements and Risks & Issues 72/1Review: Data Requirements and Risks & Issues Begin End-to-End Review End to End Review 82/8End-to-End Comments Review & disposition 19

20. Use Case Development Process 20

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

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

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

24. Scenario 1: Query for Consent Directive 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

25. Scenario 1: User Story 1 Patient X is admitted at General Hospital with a broken hip. General Hospital is an acute care hospital that is required to participate in the Comprehensive Care for Joint Replacement (CJR) payment model under the authority of the Center for Medicare and Medicaid Innovation (CMMI). The CJR program encourages hospitals, physicians, and post-acute care providers to work together to improve the quality and coordination of care from the initial hospitalization through recovery associated with hip and knee joint replacements. Although Patient X is not a Medicare beneficiary, General Hospital has found that coordinating care with local post-acute care (PAC) facilities has improved patient care and reduced cost. Although the exchange of patient medical records could be considered permitted by the HIPAA Privacy Rule under provisions that permit disclosures of protected health information (PHI) for treatment, payment, or health care operations (TPO), General Hospital wants to receive the consent of Patient X before sharing PHI with any of it's several CJR collaborator PAC facilities. Patient X is discharged from General Hospital after surgery and is transferred to Nightingale, a Skilled Nursing Facility (SNF) and a CJR collaborator for post-acute care and rehabilitation. Consistent with the CJR collaborator agreement, General Hospital assigns a specialist, Doctor Bob, to review the patient's medical record during treatment at Nightingale. Dr. Bob electronically requests Patient X's medical record from Nightingale. The Nightingale health information system receives and validates the request. Patient X is recognized as a non- beneficiary and therefore requires the patient's consent for sharing data. The Nightingale health information system queries the Consent Directive Registry to identify the location of the patient’s consent directive. The Consent Directive Registry is a shared resource used by all CJR collaborators to simplify the recording and sharing of consent information. The Consent Directive Registry responds to the query with information required to access the repository at a Patient Consent Repository. The Nightingale health information system queries the Consent Repository to retrieve the patient’s consent directive. The Nightingale health information system evaluates the patient’s consent directive against the attribute values of the request. If the patient has consented to the sharing of data with General Hospital, the data is sent. General Hospital receives Patient X's medical record from Nightingale and Doctor Bob reviews the record as part of the coordinated post- acute care of Patient X. 25

26. Scenario 2: Push Consent Directive and Authorization 26 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

27. Scenario 2: Background Alice, who is a veteran, applies for SSA disability benefits. Alice qualifies as a Wounded Warrior with a Compensation Rating of 100% Permanent and Total disability [P&T]. Military service members can receive expedited processing of disability claims from Social Security. Benefits available through Social Security are different from those from the Department of Veterans Affairs and require a separate application. Alice downloads the applicable forms including Form SSA-827 Authorization to Disclose Information to the Social Security Administration from a link in her MyHealtheVet account.separate applicationForm SSA-827 Alice lives in a state that requires the claimant to affirm his or her informed consent by initialing the white spaces to the left of each category of this section. To comply, Alice submits a hard-copy version of her online her SSA Authorization Form. She prints off a copy of an online SSA-827 form that she’s filled out online and digitally signed in order to check the boxes and sign with “wet ink”. Alice permits disclosure of all of her VHA records, including those governed under Title 38 Section 7332. Alice submits the required forms in hard-copy and electronically, using Direct from her MyHealtheVet account to SSA, which are accepted. SSA queries Veteran Health Administration via NwHIN for all of Alice’s VHA records along with an electronic scanned copy of her signed Form SSA-827, the URL of her online digitally signed Consent Directive, along with the URLs of applicable laws and informative links about how these laws apply. VHA is able to locate Alice’s records, and applies her electronic SSA Form-827 Authorization Consent Directive to determine that SSA is authorized to receive her VHA records. VHA discloses all of Alice’s records to SSA. 27

28. Scenario 2: User Story A SSA receives an electronic and hard-copy of Alice’s SSA-827 Authorization to Disclose Information to SSA. SSA is able to validate Alice’s 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 SSA’s request for all of her VHA records. 28

29. Scenario 2: User Story B VHA receives SSA’s request for all of Alice’s 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. VHA’s 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. 29

30. Next Steps If you have not already, please fill out the doodle poll with your availability for the next working group meeting during the week of January 4 th - January 8 th, 2016doodle poll »http://doodle.com/poll/3rmzr7gkmysh772xhttp://doodle.com/poll/3rmzr7gkmysh772x Provide feedback on strawman materials »http://confluence.siframework.org/display/PATCH/Use+Case+Developmenthttp://confluence.siframework.org/display/PATCH/Use+Case+Development »Suggest additional user stories or scenarios for basic choice consent 30

31. 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 31 Project Homepage http://confluence.siframework.org/display/PATCH/Patient+Choice+Home Use Case Development: http://confluence.siframework.org/display/PATCH/Use+Case+Development

32. @ONC_HealthIT@HHSONC Thank you!