Electronic Submission of Medical Documentation (esMD)

Use Case & Functional Requirements OverviewPPA Use Case Diagram Review

Dec 14, 20112:00 PM – 3:00 PM

Community Meeting

1

Today’s Agenda

2

Topic Presenter Time Allotted

Overview of Use Case Development, Purpose and Objectives

P. Patel 2:00-2:20

PPA Use Case Discussion:ScopeContext Diagram – User StoriesAssumptions

P. PatelB. Dieterle

2:20-2:50

Proposed Schedule for Future MeetingsNext Steps

P. Patel 2:50-3:00

PROVIDER PROFILES AUTHENTICATION (PPA)USE CASE

3

Use Case Development within the S&I Framework

Tools and Services

Use Case Developmentand Functional Requirements

Standards Development

Support

Certificationand Testing

Harmonization ofCore Concepts

Implementation Specifications

Pilot Demonstration Projects

Reference Implementation

Architecture Refinement and Management

4

We are

Here

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

5

Definitions: Use Case, Scenarios, and User Stories

6

Use Case

User Story 1

(Supplement to Scenario)

Scenario 1 Scenario 2The Scenario is a comprehensive description of the actors, interactions, activities, and requirements associated with the information exchange.

The User Stories summarize the interaction between the actors of the Use Case, and specify what information is exchanged from a contextual perspective.

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

User Story 2

(Supplement to Scenario)

User Story 1

(Supplement to Scenario)

User Story 2 (Supplement to Scenario)

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

7

Use Case Development Process

8

Use Case OutlineTailored for each Initiative

9

PPA Purpose and Objective (from wiki)Purpose Statement:The purpose of the PPA workgroup is to evaluate solutions to: 1. Register providers with CMS to receive electronic medical document request letters

and 2. Support CMS and other appropriate payers in securely sending medical

documentation request letters to HIHs/ProvidersThese 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.

10

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

11

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

12

PPA Use Case Context Diagram – Initial Thoughts

13

Health Information

Handler (HIH)

OR

Provider

1. HIH/Provider Sends electronic registration / Trading Partner Agreement request to CMS

2. CMS sends ESI query to PD to determine capability of provider / HIH to receive medical documentation request (MDR).

4. Confirmation of registration / Trading Partner Agreement status sent from CMS

9. Electronic medical documentation request (MDR) sent securely to Provider or HIH as needed *

CMS PD

3. ESI query response sent to CMS

* Electronic MDR is sent only when CMS identifies the need for documentation.

CMS Review Contractors

ExternalProvider

Directory

5. Sends request for provider registration status

8. Rece

ives u

pdated ESI In

formatio

n

Prov

ider

Re

gist

ratio

nSe

cure

Sen

ding

of

MDR

1A. Internally validate / verify provider and provider ID

6. Receives validation of registration status

7. Sends r

equest to re

trieve

updated ESI inform

ation

PPA Use Case Context Diagram – Information Exchange Paths – General Case

14

PayerEntities Provider

Contractors / Intermediaries

Provider Directories

Agent / Access

Access

Gate

way

PPA Use Case Context Diagram – Provider Registration

15

CMS Provider

Contractors / Intermediaries

Provider Directories

HIH

AccessesM

D Ga

tew

ay

CMS PD

1. HIH/Provider Sends electronic registration / Trading Partner Agreement request to CMS

2. CMS sends ESI query to PD to determine

capability of provider / HIH to receive medical

documentation request (MDR).

3. ESI query response sent to CMS

4. Confirmation of registration / Trading Partner Agreement status sent from CMS

In to CMSOut from CMS

PPA Use Case Context Diagram – Secure MDR transmission from CMS Contractors

16

CMS Provider

* Electronic MDR is sent only when CMS identifies the need for documentation.

Contractors / Intermediaries

Provider Directories

HIH

AccessesM

D Ga

tew

ay

In to ContractorOut from Contractor

5. Electronic medical documentation request (MDR) sent securely to Provider or HIH as needed *

1. Sends request for provider registration status

4. Receives updated

ESI Information

2. Receives validation of registration status

3. Sends request to retrieve

updated ESI informationOut to Provider

CMS PD

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

17

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

18

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

19