Electronic Submission of Medical Documentation (esMD)

1. Electronic Submission of Medical Documentation (esMD) Community Meeting

2. Today’s Agenda

3. Provider profiles authentication (PPA)use case

4. Use Case Development within the S&I Framework Pilot Demonstration Projects Standards Development Support We are Here Reference Implementation Harmonization ofCore Concepts Implementation Specifications Certificationand Testing Use Case Developmentand Functional Requirements Tools and Services Architecture Refinement and Management

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

6. Definitions: Use Case, Scenarios, and User Stories Use Case 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 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.

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

8. Use Case Development Process

9. Use Case OutlineTailored for each Initiative

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

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

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

13. PPA Use Case Context Diagram – Initial Thoughts 1. HIH/Provider Sends electronic registration / Trading Partner Agreement request to CMS 1A. Internally validate / verify provider and provider ID Health Information Handler (HIH) OR Provider 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 6. Receives validation of registration status 5. Sends request for provider 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.

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

15. 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 Provider CMS Contractors / Intermediaries 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

16. 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 Provider Contractors / Intermediaries CMS esMD Gateway 2. Receives validation of registration status HIH Access CMS PD 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.

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

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

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