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