Electronic Submission of Medical Documentation (esMD) Community Meeting Use Case & Functional Requirements Overview PPA Use Case Diagram Review Dec 14, 2011 2:00 PM – 3:00 PM

Today’s Agenda Topic Presenter Time Allotted Overview of Use Case Development, Purpose and Objectives P. Patel 2:00-2:20 PPA Use Case Discussion: Scope Context Diagram – User Stories Assumptions B. Dieterle 2:20-2:50 Proposed Schedule for Future Meetings Next Steps 2:50-3:00

Provider profiles authentication (PPA) use case

Use Case Development within the S&I Framework Standards Development Support Pilot Demonstration Projects We are Here Use Case Development and Functional Requirements Harmonization of Core Concepts Certification and Testing Implementation Specifications Reference Implementation Tools and Services Architecture Refinement and Management

Use Case Development Objectives Engage Stakeholders as Committed Members, Invited Experts, or Interested Parties in the creation of a Use Case Identify Use Case(s), Scenario(s) and User Stories that address real-world problems There can be multiple Use Cases There can be multiple Scenarios (and subsequently User Stories) within one Use Case Keep it simple Create a finalized Use Case that demonstrates value and supports the proposed goals for the Initiative Publish a finalized Use Case that contains necessary content to enable Harmonization and subsequent S&I Framework efforts to occur Establish the Use Case and supporting artifacts in a reusable fashion to support future S&I Initiatives

Definitions: Use Case, Scenarios, and User Stories The Use Case is the foundation for identifying and specifying the standards required to support the data exchange, reference implementations and tools to ensure consistent and reliable adoption of the data exchange standards The Scenario is a comprehensive description of the actors, interactions, activities, and requirements associated with the information exchange. Scenario 1 Scenario 2 Definition - http://wiki.siframework.org/ICH+-+Use+Case+and+Functional+Requirements+Development User Story 1 (Supplement to Scenario) User Story 2 (Supplement to Scenario) User Story 1 (Supplement to Scenario) User Story 2 (Supplement to Scenario) The User Stories summarize the interaction between the actors of the Use Case, and specify what information is exchanged from a contextual perspective.

Purpose and Value of Use Cases and associated Functional Requirements Use Cases: A narrative format to give contextual background of why the Initiative is necessary, and explains the benefits of the information exchange. Serves as a starting point for S&I Initiatives, and will provide input into future phases of the Initiative. Within the Use Case, there are detailed Scenarios and User Stories, which demonstrate how the enhanced technical capabilities will improve upon the existing process. Scenarios: The scenarios are accompanied by various diagrams, providing pictorial representations of the processes, and displaying the actors involved as well as the sequence of the information exchange. User Stories: The user stories summarize the interaction between the actors and specify what information is exchanged in that interaction. User stories describe the real world application of the scenario.   Functional Requirements identify the capabilities a system must have in order to enable interoperable exchange of relevant healthcare data. They provide a detailed breakdown of the intended functional behaviors of the system. The Functional Requirements include: Information Interchange Requirements System Requirements Dataset Requirements

Use Case Development Process

Use Case Outline Tailored for each Initiative

PPA Purpose and Objective (from wiki) Purpose Statement: The purpose of the PPA workgroup is to evaluate solutions to: Register providers with CMS to receive electronic medical document request letters and Support CMS and other appropriate payers in securely sending medical documentation request letters to HIHs/Providers These solutions, combined with other esMD Initiative efforts, will enable CMS Review Contractors to send electronic medical document request letters, as an alternative to current paper processes. Objective: Define the business requirements related to the registration process, compliant with CMS policies and FISMA guidelines, and determine how to securely send medical document request letters to registered providers. In addition to addressing requirements, this workgroup will also analyze and harmonize standards to support secure electronic sending of medical document request letters. Business requirements and standards will have a key focus on the needs of CMS and the CMS post-payment Review Contractors, while also considering options to enable re-use of the processes and standards by other Payers and Medicare partners.

PPA Scope (from wiki) In Scope: CMS esMD Signup/Registration process Requirements and standards pertaining to technical transport and authentication needed to allow CMS/Payers to send  medical document request letter to specific providers, either directly or via HIH Out of Scope: Structure of medical document request letter will be covered in Structured Content workgroup Authentication of content sent from Providers will be covered in the Author of Record workgroup

Introduction to Context Diagram What does it do? Visually demonstrates transaction / information exchange taking place Helps identify the Actors and their Roles Why is it helpful to develop a Context Diagram? Provides a high level overview (not too detailed) The diagram serves as a starting point to capture all the in scope items Helps identify how many Use Cases, Scenarios and User Stories will need to be developed

PPA Use Case Context Diagram – Initial Thoughts 1. HIH/Provider Sends electronic registration / Trading Partner Agreement request to CMS Health Information Handler (HIH) OR Provider 1A. Internally validate / verify provider and provider ID 2. CMS sends ESI query to PD to determine capability of provider / HIH to receive medical documentation request (MDR). External Provider Directory Provider Registration 3. ESI query response sent to CMS 4. Confirmation of registration / Trading Partner Agreement status sent from CMS CMS PD 7. Sends request to retrieve updated ESI information 5. Sends request for provider registration status 6. Receives validation of registration status Secure Sending of MDR 8. Receives updated ESI Information CMS Review Contractors 9. Electronic medical documentation request (MDR) sent securely to Provider or HIH as needed * * Electronic MDR is sent only when CMS identifies the need for documentation.

Contractors / Intermediaries PPA Use Case Context Diagram – Information Exchange Paths – General Case Provider Directories Payer Entities Contractors / Intermediaries Provider Gateway Agent / Access Access

PPA Use Case Context Diagram – Provider Registration Provider Directories In to CMS 2. CMS sends ESI query to PD to determine capability of provider / HIH to receive medical documentation request (MDR). Out from CMS 3. ESI query response sent to CMS CMS Contractors / Intermediaries Provider esMD Gateway HIH CMS PD Access 1. HIH/Provider Sends electronic registration / Trading Partner Agreement request to CMS 4. Confirmation of registration / Trading Partner Agreement status sent from CMS

PPA Use Case Context Diagram – Secure MDR transmission from CMS Contractors Provider Directories In to Contractor Out from Contractor Out to Provider 3. Sends request to retrieve updated ESI information 4. Receives updated ESI Information 1. Sends request for provider registration status CMS Contractors / Intermediaries Provider esMD Gateway 2. Receives validation of registration status HIH CMS PD Access 5. Electronic medical documentation request (MDR) sent securely to Provider or HIH as needed * * Electronic MDR is sent only when CMS identifies the need for documentation.

INITIAL DRAFT - Assumptions / Notes Ideally, request will be in a structured electronic format (not web portal) Registrations will expire at some point in time – will need to determine when at a later time Providers will be signed up at the NPI level We can assume that registration process for an individual provider vs. a hospital registering multiple providers will be the same The PD could be a provider PD, could be a 3rd party like CAQH, could be a RHIO or HIE PD (community or State) CMS will be using the esMD gateway for appropriate transactions

Schedule of Upcoming Meetings Will continue discussing PPA Use Case and Functional Requirements for next few months (target completion: end of Feb) Next meeting: 12/21 12/21 – Finalize Context Diagram, Review of Actors and Roles, Review of User Story write up 12/28 – No call due to holidays, offline discussions/homework for Assumptions, Pre and Post conditions, Begin development of Scenarios and associated diagrams and review of all items from 12/21 1/4 - First meeting of 2012 and review of offline discussions/ assigned homework

Next Steps Homework: Need volunteers to draft user story (paragraph format) to present on next call Next meeting on 12/21 Discuss draft user story write ups Verbal consensus on PPA diagram Discuss Actors and Roles