1. S&I Framework Prescription Drug Monitoring Program & Health IT Integration Initiative Use Case & Functional Requirements Kickoff Meeting January 7, 2014 1

2. Use Case Development Objectives Engage Stakeholders as Committed Members, Invite Experts, or Interested Parties in the creation of a Use Case  This is you all! 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 enable Harmonization and subsequent S&I Framework efforts to occur 2

3. 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.2 Out of Scope –3.3 Communities of Interest (Stakeholders)** 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 Use Case Outline Tailored for each Initiative 10.0 Scenario: Workflow –10.1 User Story 1, 2, x, … –10.2 Activity Diagram o 10.2.1 Base Flow o 10.2.2 Alternate Flow (if needed) –10.3 Functional Requirements o 10.3.1 Information Interchange Requirements o 10.3.2 System Requirements –10.4 Sequence Diagram 11.0 Dataset Requirements 12.0 Risks, Issues and Obstacles Appendices –Privacy and Security Considerations –Related Use Cases –Previous Work Efforts –References ** Leverage content from Charter 3

4. Assumptions Outlines what needs to be in place to meet or realize the requirements of the Use Case These points are more functional in nature and state the broad overarching concepts related to the Initiative. The Use Case assumptions will 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. It lists what needs to be in place before executing the information exchange as described by the 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. Review of Key Use Case Sections Assumptions, Pre-conditions and Post-conditions 4

5. Review of Key Use Case Sections Use Case Diagrams Conceptually represents the Business Actors interacting with the Use Case and the User Stories Provides a pictorial representation of the environment where the exchange takes place Characterizes the types of interactions that an actor has with a specific system Shows the association and interaction between the business actors and the Use Case It provides an overview of the actors (users or external systems) and the interactions between them 5 Example: Transitions of Care

6. Review of Key Use Case Sections Defining the Actors This section of the Use Case outlines the business actors that are participants in the information exchange requirements for each scenario. A business actor is a person or organization that directly participates in a scenario. The business actor must use a system to perform the functions and to 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. Please see the table below for an example of these designations. ActorSystemRole PCPEHR SystemSender SpecialistEHR SystemReceiver PatientPHR SystemReceiver Example 6

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

8. Review of Key Use Case Sections User Story User Stories describe the real world application as an example or instantiation of the Scenario User Stories summarize the interaction between the actors of the Use Case, and specify what information is exchanged from a contextual perspective These 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. 8

9. Review of Key Use Case Sections Activity Diagram An Activity Diagram is a special form of a state transition diagram in which all or most of the states are activity states or action states The Activity Diagram illustrates the Use Case flows graphically, and represents the flow of events and information between the actors –It also displays the main events/actions that are required for the data exchange and the role of each system in supporting the change 9

10. Review of Key Use Case Sections Functional Requirements Functional Requirements identify the capabilities a system in a role must have in order to enable interoperable exchange of the healthcare data of interest –They provide a detailed breakdown of the requirements in terms of the intended functional behaviors of the application The Functional Requirements include: –Information Interchange Requirements –System Requirements The Information Interchange Requirements define the system’s name and role. They also specify the actions associated with the actual transport of content from the sending system to the receiving system System Requirements include the requirements internal to the system necessary to participate successfully in the transaction. System requirements may also detail a required workflow that is essential to the Use Case 10

11. A Sequence Diagram is primarily used to show the interactions between objects in the sequential order that they occur –This representation can make it easy to communicate how the exchange works by displaying how the different components interact –The primary use of the diagram is in the transition from requirements expressed as use cases to the next and more formal level of refinement Note: Horizontal lines are used to identify the specific activity between the systems Review of Key Use Case Sections Sequence Diagram 11

12. Dataset Requirements Include the data elements and data element sets that will be available within the message or document. Each data element included is necessary for some aspect of the Use Case; however, the requirements do not specify exactly how they may be used together. All data element sets may contain multiple data elements unless otherwise stated. The identification of data elements forms the foundation for harmonization activities. The data elements identified in the Use Case set constraints on the contents of documents and messages. Issues Risks and Obstacles Lists the concerns that might interfere with meeting the requirements of the Use Case. Note: This list takes into consideration risks outlined in the Charter Review of Key Use Case Sections Dataset Requirements & Issues, Risks & Obstacles 12

13. S&I Community Enabling Toolkit (CET) Use Case Overview 13

14. Prescription Drug Monitoring Program & Health IT Integration Use Case Discussion 14

15. PDMP & HIT Integration Initiative Proposed Use Case & Functional Requirements Development Timeline Week Target Date (2014) All Hands WG Meeting Tasks Review & Comments from Community via Wiki page due following Monday @ 12 noon 11/7 Use Case Kick-Off & UC Process Overview Introduce: In/Out of Scope, Context Diagram and Scenario Concert Series Presentation: ASAP Review: In/Out of Scope, Scenario and Assumptions sections 21/14 Review: In/Out of Scope, Context Diagram, Assumptions, Scenario Introduce: User Stories Review: User Stories, Context Diagram, Assumptions, Pre/Post Conditions 31/21 Review: User Stories Introduce: Pre/Post Conditions, Actor and Roles Review: User Stories, Pre/Post Conditions, Base Flow and Activity Diagram 41/28 Review: Finalize User Stories, Pre/Post conditions Introduce: Activity Diagram and Base Flow Concert Series Presentation: OnePort Health Review: Activity Diagram, Base Flow and Functional Requirements 52/4 Review Activity Diagram and Base Flow Introduce: Functional Requirements & Sequence Diagram Review: Functional Requirements, Sequence Diagram, Data Requirements 62/11 Review Functional Requirements Introduce: Data Requirements Review: Data Requirements 7 2/18 (To be rescheduled) Review: Data Requirements and Risks & Issues Begin End-to-End Review End-to-End Review by community 2/25HIMSS Meeting 83/4End-to-End Comments Review & dispositionEnd-to-End Review ends 93/11Finalize End-to-End Review Comments & Begin ConsensusBegin casting consensus vote 103/18Consensus Vote*Conclude consensus voting 15

16. PDMP & HIT Integration – Use Case Assumptions 1.Health IT system is capable of querying a PDMP 2.All Healthcare Professionals have appropriate legal authority based on state regulations to request and receive information from state PDMP 3.Healthcare Professionals accessing the PDMP follow state guidelines as appropriate, including any privacy and security requirements as required by each individual state PDMP authority 4.The PDMP returns high positive matches to the Healthcare Professional 1 5.The Healthcare Professional accesses information that already exists within the PDMP at the time of querying Definitions Healthcare Professional- A medical practitioner or provider of care who has legal authorization to access prescription drug data for patients at the point of care to make informed clinical decisions and appropriate treatment recommendations This may include: Prescribers, dispensers, nurses, etc. Health IT System – An information system that is used by a Healthcare Professional to collect and store patient information including demographics, medicine, etc. (i.e. EHR, HIE, Pharmacy System) 1 Question for Community: What are the responses you receive when querying a PDMP? 16

17. PDMP & HIT Integration – In and Out of Scope In Scope 1.Connecting PDMPs to Health IT systems using existing standards; (technical mechanism for actual exchange of data)** 2.If standards do not exist, identifying the gap in the current standards and working with the Standards Organizations (SDOs) to address the gaps** (Refers to harmonization activity) 3.Improving effective and efficient access to PDMP data by Healthcare Professionals** 4.Health IT system has ability to view query response from PDMP 1.Healthcare Professional querying PDMP for a known patient through a Health IT system 2.Healthcare Professional querying a state PDMP connected to the same hub as the state they are located in 5.Safety notifications/ automated alerts from PDMP 6.Define standard set of data elements used to submit queries each time 7.Define system /technical requirements for Healthcare Professionals to be able to access patient information already stored in a PDMP 1.Accessing a PDMP through a Health IT system (i.e. EHR system) instead of another portal 8.Define system/technical requirements that allow applications to access data in a consistent manner across the local Health IT system 1.Method of extraction Out of Scope 1.Defining the trigger event for how the PDMP is queried or initiated by the user (e.g., hyperlink while ordering, pressing a button, automatic trigger, etc.)** 2.Addressing delegation of rights to individuals not legally authorized to prescribe medications (this is an implementation specific decision and may vary by implementation and pilot sites)** 3.Third party access - (this is an implementation specific decision and may vary by implementation, pilot sites and state statues and law)** 4.Reporting patient prescription information from dispensers to state PDMP 5.Policy-based decisions on how PDMPs are managed, accessed, and updated that vary from state to state 6.Timeliness of PDMP: Currency of Data 7.Storing query response from PDMP 8.Health IT system’s structure of display for the query response 17 **Leveraged from Charter

18. Generic Scenario & Context Diagram Pre-Step: Healthcare Professional logs into Health IT System 1. Sends query to state PDMP Healthcare Professional receives requested information PDMP & HIT Integration Use Case Scope 2. PDMP sends query response Pre-Step: Healthcare Professional logs into Health IT System 1. Sends query to state PDMP Healthcare Professional receives requested information PDMP & HIT Integration Use Case Scope 2. PDMP sends query response Interstate Hub AND/OR 18

19. Next Steps Review In/Out of Scope, Scenario and Assumptions sections Next Meeting is Tuesday, January 14 from 12:00pm - 1:00pm EST Reminder: All PDMP & HIT Integration Announcements, Meeting Schedules, Agendas, Minutes, Reference Materials, Use Case, Project Charter and general information will be posted on the PDMP Wiki page –http://wiki.siframework.org/PDMP+%26+Health+IT+Integration+ Homepagehttp://wiki.siframework.org/PDMP+%26+Health+IT+Integration+ Homepage 19

20. Contact Information For questions, please feel free to contact your support leads: – Initiative Coordinators: Johnathan Coleman jc@securityrs.comjc@securityrs.com Sherry Green sgreen@namsdl.orgsgreen@namsdl.org – ONC Leads: Mera Choi mera.choi@hhs.govmera.choi@hhs.gov Jennifer Frazier Jennifer.Frazier@hhs.govJennifer.Frazier@hhs.gov Helen Caton-Peters Helen.Caton-Peters@hhs.govHelen.Caton-Peters@hhs.gov – SAMHSA Leads Jinhee Lee Jinhee.Lee@samhsa.hhs.govJinhee.Lee@samhsa.hhs.gov Kate Tipping Kate.Tipping@samhsa.hhs.govKate.Tipping@samhsa.hhs.gov – Support Team: Project Management: – Jamie Parker jamie.parker@esacinc.comjamie.parker@esacinc.com – Ali Khan Ali.Khan@esacinc.com (Support)Ali.Khan@esacinc.com Use Case Development: – Ahsin Azim Ahsin.Azim@accenturefederal.comAhsin.Azim@accenturefederal.com – Presha Patel presha.patel@accenture.compresha.patel@accenture.com Vocabulary and Terminology Subject Matter Expert: – Mark Roche mrochemd@gmail.commrochemd@gmail.com 20