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); Emily Mitchell (Use Case); Presha Patel (Use Case); William Ryan (Harmonization); Shay Paintal (Harmonization); Sweta Ladwa (Overall); 16