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

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

3. Provider profiles authentication (PPA) use case

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

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

8. Use Case Development Process

9. Use Case Outline Tailored 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
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.

14. Contractors / Intermediaries
PPA Use Case Context Diagram – Information Exchange Paths – General Case
Provider Directories
Payer
Entities
Contractors / Intermediaries
Provider
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
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

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

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