esMD Use Case 1: Introduction to Harmonization

1. esMD Use Case 1: Introduction to Harmonization 1

2. esMD Initiative: Harmonization Process Harmonization for Use Case 1 may include the following steps: • Expand dataset requirements into a full data model • Reuse elements from PD Data Model and CEDD • Review and select standards identified by SDS • Choose standards based on use case, data model requirements, and community expertise • Map data model to select standards • Identify gaps and work with SDS to communicate needs with SDOs • 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) • Develop Implementation Guide(s) for CMS and commercial payers • Guide should enable implementation of data model and registration request processes 2

3. esMD Initiative: Harmonization Process 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. • Expand dataset requirements into a full data model • Reuse elements from PD Data Model and CEDD • Review and select standards identified by SDS • Choose standards based on use case and data model requirements and community expertise • Map data model to select standards • Identify gaps and work with SDS to communicate needs with SDOs • 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) • Develop Implementation Guide(s) for CMS and commercial payers • Guide should enable implementation of data model and registration request processes 3

4. esMD Initiative Notional Timeline Sept 2012 Aug 2012 Oct 2011 Nov 2011 Dec 2011 Jan 2012 Feb 2012 Mar 2012 Apr 2012 May 2012 Jun 2012 Jul 2012 Oct 2012 PPA Workgroup PPA Use Case 1 Development Outline Use Cases and Stories Harmonization Phase PPA Use Case 2 Development Structured Content Development Combined Harmonization of PPA Use Case 1, Use Case 2, and Structured Content Initial Harmonization of PPA Use Case 1 Combined Registration and eMDR Pilot

5. esMD Initiative: Harmonization Process Our initial focus will be the development of the esMD PPA data model • Expand dataset requirements into a full data model • Reuse elements from PD Data Model and CEDD • Review and select standards identified by SDS • Choose standards based on use case and data model requirements and community expertise • Map data model to select standards • Identify gaps and work with SDS to communicate needs with SDOs • 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) • Develop Implementation Guide(s) for CMS and commercial payers • Guide should enable implementation of data model and registration request processes 5

6. esMD PPA Data Set Requirements The Use Case identified data elements necessary for the provider registration request and response processes. The dataset requirements includes the following columns: • Sections – groups of related data elements • Data element – specific information necessary for registration process • Multiple Values – indicates need to support multiple, uniquely valued instances of a data element • Description – brief description of data element purpose and content • Notes – additional information to further clarify purpose, content, format, or some other aspect of the data element 6

7. esMD PPA Data Model Development We will expand the data set into a full data model by adding columns for the following information: • Definitions • Comments • Cardinality • Datatypes • Standard Format/Vocabulary 7

8. Definition and Comments • 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. 8

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

10. Datatype Datatype defines the best approach for representing each data element when implemented in a computer. Possible datatypesinclude: • String • Integer • Code • Date • Binary Object • URL 10

11. Standard Format / Vocabulary 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: • Phone number format: (###) ### - #### • List of Status values: Active, Inactive, Revoked, Suspended • List of Degree values: MD, DO, DC, PhD, BS, BA, MPH, MS, MA, RN, LVN, LPT, OTR, AuD, OD 11

12. esMD PPA Data Model spreadsheet We will develop the data model by working directly from a spreadsheet on GoogleDocs. 12

13. Provider Directories Data Model • 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. 13

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

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

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