esMD Use Case 1: Introduction to Harmonization

esMD Use Case 1: Introduction to Harmonization

1

esMD Initiative: Harmonization Process

Harmonization for Use Case 1 may include the following steps:

1. Expand dataset requirements into a full data model• Reuse elements from PD Data Model and CEDD

2. Review and select standards identified by SDS• Choose standards based on use case, data model requirements, and community

expertise

3. Map data model to select standards• Identify gaps and work with SDS to communicate needs with SDOs

4. Develop registration processes for CMS and commercial payers• Expand on Section 10 in Use Case 1 document to prepare detailed process

guidance for Implementation Guide(s)

5. Develop Implementation Guide(s) for CMS and commercial payers• Guide should enable implementation of data model and registration request

processes

2

In order to align Use Case 1 and Use Case 2 to the same standards, we will focus on steps 1 and 4 while Use Case 2 is under development. We will continue with steps 2, 3, and 5 when Use Case 2 is complete.

1. Expand dataset requirements into a full data model• Reuse elements from PD Data Model and CEDD

2. Review and select standards identified by SDS• Choose standards based on use case and data model requirements and

community expertise

3. Map data model to select standards• Identify gaps and work with SDS to communicate needs with SDOs

4. Develop registration processes for CMS and commercial payers• Expand on Section 10 in Use Case 1 document to prepare detailed process

guidance for Implementation Guide(s)

5. Develop Implementation Guide(s) for CMS and commercial payers• Guide should enable implementation of data model and registration request

processes

esMD Initiative: Harmonization Process

3

esMD Initiative Notional Timeline

PPA Use Case 2 Development

Initial Harmonization

of PPA Use Case 1

Combined Registration and

eMDR Pilot

PPA Workgroup

Jul 2012

Oct 2011

Nov 2011

Dec 2011

Jan 2012

Feb 2012

Mar 2012

Apr 2012

May 2012

Jun 2012

Aug 2012

Sept 2012

Oct 2012

Combined Harmonization of PPA Use Case 1, Use Case 2, and Structured Content

Outline Use Cases and Stories Harmonization Phase

PPA Use Case 1 Development

Structured Content Development

4

Our initial focus will be the development of the esMD PPA data model

1. Expand dataset requirements into a full data model• Reuse elements from PD Data Model and CEDD

2. Review and select standards identified by SDS• Choose standards based on use case and data model requirements and

community expertise

3. Map data model to select standards• Identify gaps and work with SDS to communicate needs with SDOs

4. Develop registration processes for CMS and commercial payers• Expand on Section 10 in Use Case 1 document to prepare detailed process

guidance for Implementation Guide(s)

5. Develop Implementation Guide(s) for CMS and commercial payers• Guide should enable implementation of data model and registration request

processes

esMD Initiative: Harmonization Process

5

The Use Case identified data elements necessary for the provider registration request and response processes. The dataset requirements includes the following columns:

1. Sections – groups of related data elements

2. Data element – specific information necessary for registration process

3. Multiple Values – indicates need to support multiple, uniquely valued instances of a data element

4. Description – brief description of data element purpose and content

5. Notes – additional information to further clarify purpose, content, format, or some other aspect of the data element

esMD PPA Data Set Requirements

6

We will expand the data set into a full data model by adding columns for the following information:

1. Definitions

2. Comments

3. Cardinality

4. Datatypes

5. Standard Format/Vocabulary

esMD PPA Data Model Development

7

• Definitions define the intended purpose of a data element. Goals include clarity, simplicity, and consistency with other initiatives.

• Comments provide additional information about a data element that may assist an implementer in using the data model. This may include additional context, example values, or suggestions for use.

Definition and Comments

8

Cardinality defines the number of uniquely valued instances of a data element allowed within a transaction. Possible values include:

• 1 – The data element is required in a transaction. Only a single instance of the data element is allowed.

• 1..n – The data element is required in a transaction. One or more instances of the data element are allowed.

• 0,1 – The data element is optional in a transaction. If it is included, only a single instance of the data element is allowed.

• 0..n – The data element is optional in a transaction. If it is included, one or more instances of the data element are allowed.

Cardinality

9

Datatype defines the best approach for representing each data element when implemented in a computer. Possible datatypes include:

1. String

2. Integer

3. Code

4. Date

5. Binary Object

6. URL

Datatype

10

Standard format and vocabulary define either the recommended format a data element value should take or a defined list of values the data element may take. Examples include:

1. Phone number format: (###) ### - ####

2. List of Status values: Active, Inactive, Revoked, Suspended

3. List of Degree values: MD, DO, DC, PhD, BS, BA, MPH, MS, MA, RN, LVN, LPT, OTR, AuD, OD

Standard Format / Vocabulary

11

esMD PPA Data Model spreadsheet

12

We will develop the data model by working directly from a spreadsheet on GoogleDocs.

• The PD Initiative developed a data model to support the querying of provider directories to discover electronic service information (ESI).

– ESI is the information reasonably necessary to define an electronic destination and its ability to receive and consume a specific type of information, including the destination’s electronic address, message framework, payload specification, and required security artifacts.

• The PD data model includes data elements similar to those identified in the esMD PPA dataset requirements.

– Not surprising given that payer will use data from the registration request transaction to query a provider directory for a provider’s ESI as part of the registration process

• The esMD workgroup can reuse definitions, comments, and datatypes from the PD data model as it sees fit.

Provider Directories Data Model

13

In order to simplify development of the esMD PPA data model, we have included similar elements from the PD data model in the spreadsheet.

Provider Directories Data Model

14

Meeting schedules

Use Case 2 Development will take place concurrently with the initial phase of Use Case 1 Harmonization.

• Use Case 2 Development– Wednesdays, 1:30 – 3:00 PM EST– Fridays, 2:00 – 3:00 PM EST

• Use Case 1 Harmonization– Wednesdays, 10:00 – 11:00 AM EST

15

Next Steps / Questions

• Next Work Group Meeting • Use Case 1 Consensus/Use Case 2 Development - Wednesday, March 13th 1:30pm -

3:00pm

• For questions, please feel free to contact esMD support leads• Sam Elias (IC); sam.elias@sghealthit.com• Emily Mitchell (Use Case); emily.d.mitchell@accenture.com• Presha Patel (Use Case); presha.patel@accenture.com• William Ryan (Harmonization); wiryan@deloitte.com• Shay Paintal (Harmonization); spaintal@deloitte.com• Sweta Ladwa (Overall); sweta.ladwa@esacinc.com

16