Medicare Advantage Supplemental Dental Services Submission Guide 2-28-2024 Clean 1.1 (1)

Medicare Advantage Supplemental Dental Services Submission Guide Version 1.1

Medicare Advantage Supplemental Dental Services Submission Guide

Instructions related to the 837D Health Care Claim: Medicare Advantage Dental Transaction based on ASC X12 Technical Report Type 3 (TR3), Version 005010X224A2

Version Number: 1.1

Created: February 2024

Contents

1 Introduction

1.1 Statutory and Regulatory Background 3

1.2 Scope 3

1.3 Overview 4

2 Contact Information 4

2.1 The Customer Service and Support Center (CSSC) 4

3 File Submission 5

3.1 Enrolling to Submit Dental Encounter Data 5

3.2 File Naming Conventions 5

3.3 File Size Limitations 5

3.4 File Structure – NDM/Connect:Direct Submitters Only 5

4 Control Segments/Envelopes 6

4.1 ISA/IEA 6

4.2 GS/GE 7

4.3 ST/SE 8

5 837 MA Supplemental Dental: Data Elements 9

6 Acknowledgements and/or Reports 11

6.1 TA1 – Interchange Acknowledgement 11

6.2 999 – Functional Group Acknowledgement 11

6.3 Dental Validation Report 12

6.4 Reports File Naming Conventions 12

6.4.1 Testing Reports File Naming Convention 12

6.4.2 Production Reports File Naming Convention 14

7 MA Supplemental Dental Testing and Certification 14

8 Acronyms 15

1. Introduction

   1. Statutory and Regulatory Background 

CMS requires organizations providing services or items to Medicare Advantage (MA) beneficiaries to submit data that characterize the context and purpose of each item and service provided to a Medicare beneficiary, as described in regulation at 42 CFR 422.310. The regulation at 422.310(b)¹ states, “Each MA organization must submit to CMS (in accordance with CMS instructions) the data necessary to characterize the context and purposes of each item and service provided to a Medicare enrollee by a provider, supplier, physician, or other practitioner. CMS may also collect data necessary to characterize the functional limitations of enrollees of each MA organization.” 

In 2008, CMS revised 42 CFR 422.310(d) to further clarify that CMS has the authority to require MA organizations to submit encounter data for each item and service provided to an MA plan enrollee to fulfill the requirements provided at 422.310(b).³ 

The requirements and authorities codified at 42 CFR 422.310 apply not only to Medicare Part A and B covered items and services, but also extend to supplemental benefits offered by MA organizations, i.e., MA organizations are required to submit encounter data for supplemental benefits provided to their enrollees. While MA organizations have always been able to submit some supplemental benefits to the Encounter Data System (EDS), not all MA organizations have regularly submitted the supplemental benefits that could be submitted. Further, a number of these benefits could not be submitted because certain data elements required for EDS to accept the data did not exist and, in some situations, CMS has not provided specific instructions for the submission of supplemental benefits.  Also, CMS did not accept the 837D on which supplemental dental benefits would be submitted. 

In this document, CMS provides instructions on how to submit encounter data records (EDRs) for supplemental dental benefits into the EDS.

2. Scope

The purpose of this document is to provide MA organizations with instructions specific to populating and submitting encounter data records (EDRs) for supplemental dental benefit services. Supplemental dental benefits cover preventive and comprehensive dental services outside of Medicare-covered dental services; the context and purpose of these benefits are best captured via a dental-specific format. As such, supplemental dental benefits are to be reported using the X12 837D Version 5010 claims format. Medicare-covered dental services must continue to be submitted using the 837P for dental services that are Part B benefits or the 837I for dental services that are Part A benefits.

MA organizations are responsible for referencing other documents for general EDR submission needs. 

Please note that the information contained in this document will be incorporated into a future version of the Encounter Data Submission and Processing Guide. 

For unusual scenarios, challenges faced, or any other questions related to the requirements discussed in this document, contact [email protected]. Please specify “837D Supplemental Benefits Submission” in the subject line. This guidance does not apply to Medicare Medicaid plans. Questions regarding the contents of this Medicare Advantage Supplemental Dental Services Submission Guide should be directed to [email protected].

CMS will notify submitters when the EDS begins accepting supplemental dental encounters using the 837D format; we expect that this will be around June 2024. At that time, we expect that MA organizations will begin to submit supplemental dental benefits for dates of services beginning January 1, 2024, and we expect submissions (notwithstanding runout) to be caught up by the end of 2024.

3. Overview

The MASDS Guide includes information required to initiate and maintain communication exchange with CMS. The Guide is organized as follows:

• Contact Information: Includes telephone numbers and email addresses for the Encounter Data Front-End System (EDFES) contacts.

• File Submission: Includes file naming conventions, file size limitations, and file structure.

• Control Segments/Envelopes: Includes information required to create the ISA/IEA, GS/GE, and ST/SE control segments for transactions to be supported by the EDFES.

• 837 Dental Data Elements: Includes information on required data elements.

• Acknowledgements and Reports: Includes information for all transaction acknowledgements and reports sent by the EDFES.

• Transaction Specific Information: Describes the details of the HIPAA X12 TR3, using a tabular format. The tables contain a row for each segment with CMS and TR3 specific information.

• Testing and Certification Requirements.

2. Contact Information

1. The Customer Service and Support Center (CSSC)

The CSSC Operations help desk is available from 8:00 AM – 7:00 PM ET, Monday-Friday, except for federal holidays. MA organizations and other organizations can contact the CSSC by phone at 1-877-534-2772, (Option 2) or by email at [email protected].

3. File Submission

1. Enrolling to Submit Supplemental Dental Encounter Data

Refer to the EDI Onboarding and Connectivity section of the CSSC Operations website. https://csscoperations.com/.

2. File Naming Conventions

Refer to the Medicare Advantage and Part D Communications Handbook located on the CSSC Operations website under the EDI Onboarding and Connectivity section.

3. File Size Limitations

Due to system limitations, ISA/IEA transaction sets should not exceed 5,000 encounters, as EDFES processes smaller files more efficiently than larger files.

To support and provide the most efficient processing system, and to allow for maximum performance, CMS recommends that Secure File Transfer Protocol (SFTP) submitters’ scripts upload no more than one (1) file per five (5) minute intervals. Zipped files should contain one (1) file per transmission. NDM/Connect:Direct users may submit a maximum of 255 files per day.

4. File Structure – NDM/Connect:Direct Submitters Only

NDM/Connect:Direct submitters must format all submitted files in an 80-byte fixed block format. This means MA organizations and other entities must upload every line (record) in a file with a length of 80 bytes/characters.

Submitters should create files with segments stacked, using only 80 characters per line. At position 81 of each segment, MA organizations and other entities must create a new line. On the new line starting in position 1, continue for 80 characters, and repeat creating a new line in position 81 until the file is complete. If the last line in the file does not fill to 80 characters, the submitter should space the line out to position 80 and then save the file.

Note: If MA organizations and other entities are using a text editor to create the file, pressing the Enter key will create a new line. If MA organizations and other entities are using an automated system to create the file, create a new line by using a Carriage Return Line Feed (CRLF) or a Line Feed (LF).

For example, the ISA record is 106 characters long:

The first line of the file will contain the first 80 characters of the ISA segment; the last 26 characters of the ISA segment continue on the second line. The next segment will start in the 27th position and continue until column 80.

ISA*00* *00* *ZZ* ENH9999*ZZ* 80896*120816*114

4*^*00501*000000031*1*P*:~

Note: If a submitter has not established a sufficient number of Generated Data Groups (GDGs) to accommodate the number of files returned from the EDFES, not all of the EDFES Acknowledgement reports will be stored in the submitter’s system. To prevent this situation, NDM/Connect:Direct submitters should establish a limit of 255 GDGs in their internal processing systems.

4. Control Segments/Envelopes

1. ISA/IEA

The term interchange denotes the transmitted ISA/IEA envelope. Interchange control is achieved through several “control” components, as defined in Table 4A. The interchange control number is contained in data element ISA13 of the ISA segment. The identical control number must also occur in data element IEA02 of the IEA segment. MA organizations and other entities must populate all elements in the ISA/IEA interchange. There are several elements within the ISA/IEA interchange that must be populated specifically for MA Supplemental Dental (see Table 5B) purposes. Table 4A below provides those specific Interchange Control (ISA/IEA) elements.

Note: Table 4A presents only those elements that provide specific details relevant to MA organization data. When developing the Medicare Advantage data system, users should base their logic on the highest level of specificity.

First, consult the X12 TR3. Second, consult the MASDS Guide. If there are options expressed in the TR3 that are broader than the options identified in this guide^{, MA organizations and other entities must use the rules} identified in the MASDS Guide.

LEGEND

SHADED rows represent segments in the X12N TR3

NON-SHADED rows represent data elements in the X12N TR3

TABLE 4A – ISA/IEA INTERCHANGE ELEMENTS

LOOP ID	REFERENCE	NAME	CODES	NOTES/COMMENTS
ISA		Interchange Control Header
	ISA01	Authorization Information Qualifier	00	No authorization information present
	ISA02	Authorization Information		Use 10 blank spaces
	ISA03	Security Information Qualifier	00	No security information present
	ISA04	Security Information		Use 10 blank spaces
	ISA05	Interchange ID Qualifier	ZZ	CMS expects to see a value of “ZZ” to designate that the code is mutually defined
	ISA06	Interchange Sender ID		Submitter ID assigned by Palmetto GBA
	ISA07	Interchange ID Qualifier	ZZ	CMS expects to see a value of “ZZ” to designate that the code is mutually defined
	ISA08	Interchange Receiver ID	80896	MA Supplemental Dental
	ISA11	Repetition Separator	^
	ISA13	Interchange Control Number		Must be fixed length with nine (9) characters and match IEA02 Used to identify file level duplicate collectively with GS06, ST02, and BHT03
	ISA14	Acknowledgement Requested	1	A TA1 will be sent if the file is syntactically incorrect, otherwise only a ‘999’ will be sent
	ISA15	Usage Indicator	T P	Test Production
IEA		Interchange Control Trailer
	IEA02	Interchange Control Number		Must match the value in ISA13

2. GS/GE

The functional group is outlined by the functional group header (GS segment) and the functional group trailer (GE segment). The functional group header starts and identifies one or more related transaction sets and provides a control number and application identification information. The functional group trailer defines the end of the functional group of related transaction sets and provides a count of contained transaction sets.

MA organizations and other entities must populate all elements in the GS/GE functional group. There are several elements within the GS/GE that must be populated specifically for MA Supplemental Dental data collection (see Table 5B). Table 4B below provides those specific Functional Group (GS/GE) elements.

TABLE 4B - GS/GE FUNCTIONAL GROUP ELEMENTS

LOOP ID	REFERENCE	NAME	CODES	NOTES/COMMENTS
GS		Functional Group Header
	GS02	Application Sender’s Code		Submitter ID assigned by Palmetto GBA This value must match the value in ISA06
	GS03	Application Receiver’s Code	80896	This value must match the value in ISA08
	GS06	Group Control Number		This value must match the value in GE02 Used to identify file level duplicates collectively with ISA13, ST02, and BHT03

LOOP ID	REFERENCE	NAME	CODES	NOTES/COMMENTS
	GS08	Version/Release/Industry Identifier Code	005010X224A2
GE		Functional Group Trailer
	GE02	Group Control Number		This value must match the value in GS06

3. ST/SE

The transaction set (ST/SE) contains required, situational loops, unused loops, segments, and data elements. The transaction set is outlined by the transaction set header (ST segment) and the transaction set trailer (SE segment). The transaction set header identifies the start and identifies the transaction set. The transaction set trailer identifies the end of the transaction set and provides a count of the data segments, which includes the ST and SE segments. Several elements must be populated specifically for MA Supplemental Dental encounter data purposes (see Table 5B).

Table 4C provides those specific Transaction Set (ST/SE) elements.

TABLE 4C - ST/SE TRANSACTION SET HEADER AND TRAILER ELEMENTS

LOOP ID	REFERENCE	NAME	CODES	NOTES/COMMENTS
ST		Transaction Set Header
	ST01	Transaction Set Identifier Code	837
	ST02	Transaction Set Control Number		This value must match the value in SE02 Used to identify file level duplicates collectively with ISA13, GS06, and BHT03
	ST03	Implementation Convention Reference	005010X224A2
LOOP ID	REFERENCE	NAME	CODES	NOTES/COMMENTS
SE		Transaction Set Trailer
	SE01	Number of Included Segments		Must contain the actual number of segments within the ST/SE
	SE02	Transaction Set Control Number		This value must match the value in ST02

5. 837 MA Supplemental Dental: Data Elements

Within the ST/SE transaction set, there are multiple loops, segments, and data elements that provide billing provider, subscriber, and patient level information. MA organizations and other entities should reference https://x12.org/ to obtain the most current TR3. MA organizations and other entities must submit EDFES transactions using the most current transaction version.

The 837 MA Supplemental Dental Data Element table identifies only those elements within the X12N TR3 that require comment within the context of the EDFES’ submission. Tables 5A and 5B identify the 837 Dental TR3 by loop name, segment name, segment identifier, data element name, and data element identifier for cross reference. Not all data elements listed in the tables below are required, but if they are used, the table reflects the values CMS expects to see.

TABLE 5A – BEGINNING OF HIERARCHIAL TRANSACTION

LOOP ID	REFERENCE	NAME	CODES	NOTES/COMMENTS
	BHT	Beginning of Hierarchical Transaction
	BHT03	Originator Application Transaction Identifier		Must be a unique identifier across all files Used to identify file level duplicates collectively with ISA13, GS06, and ST02.
	BHT06	Claim Identifier	CH	Chargeable

TABLE 5B - 837 MA SUPPLEMENTAL DENTAL DATA ELEMENTS

LOOP ID	REFERENCE	NAME	CODES		NOTES/COMMENTS
1000A	NM1	Submitter Name
	NM109	Submitter Identifier			Submitter ID assigned by Palmetto GBA
1000B	NM1	Receiver Name
	NM103	Receiver Name			MADCMS
	NM109	Receiver ID	80896		MA Supplemental Dental
2000B	SBR	Subscriber Information
	SBR01	Payer Responsibility Number Code	S		MADCMS is considered the destination (secondary) payer
	SBR09	Claim Filing Indicator Code	17		MA Supplemental Dental
LOOP ID	REFERENCE	NAME	CODES	NOTES/COMMENTS
2010BA	NM1	Subscriber Name
	NM108	Subscriber ID Qualifier	MI	Must be populated with a value of MI – Member Identification Number
	NM109	Subscriber Primary Identifier		This is the subscriber’s Medicare Beneficiary Identifier (MBI) number. Must match the value in Loop 2330A, NM109.
2010BB	NM1	Payer Name
	NM103	Payer Name		MADCMS
	NM109	Payer Identification	80896	MA Supplemental Dental
2010BB	REF	Other Payer Secondary Identifier
	REF01	Contract ID Identifier	2U
	REF02	Contract ID Number		MA organization or other entities Contract ID Number
2300	REF	Payer Claim Control Number
	REF01	Original Reference Number	F8
	REF02	Payer Claim Control Number		Identifies the Interchange Control Number (ICN) from the original encounter when submitting adjustments
2320	AMT	Payer Paid Amount
	AMT01	Amount Qualifier	D	Must be populated with a value of D – Payer Amount Paid
	AMT02	Payer Paid Amount		MA Supplemental Dental plan paid amount

6. Acknowledgements and/or Reports

   1. TA1 – Interchange Acknowledgement

The TA1 report enables the receiver to notify the sender when there are problems with the interchange control structure. As the interchange envelope enters the EDFES, the Electronic Data Interchange (EDI) translator performs TA1 validation of the control segments/envelope. The sender will only receive a TA1 if there are syntax errors in the file. Errors found in this stage will cause the entire X12 interchange to be rejected with no further processing.

MA organizations and other entities will receive a TA1 interchange report acknowledging the syntactical inaccuracy of an X12 interchange header ISA and trailer IEA and the envelope’s structure.

Encompassed in the TA1 is the interchange control number, interchange date and time, interchange acknowledgement code, and interchange note code. The interchange control number, date, and time are identical to those populated on the original 837-D ISA line, which allows for MA organizations and other entities to associate the TA1 with a specific file previously submitted.

Within the TA1 segment, MA organizations and other entities will be able to determine if the interchange was rejected by examining the interchange acknowledgement code (TA104) and the interchange note code (TA105). The interchange acknowledgement code stipulates whether the interchange (ISA/IEA) was rejected due to syntactical errors. An “R” in the TA104 data element indicates the interchange rejected due to errors. The interchange note code is a numeric code that notifies MA organizations and other entities of the specific error. If a fatal error occurs, the EDFES generates and returns the TA1 interchange acknowledgement report within 24 hours of the interchange submission. If a TA1 interchange control structure error is identified, MA organizations and other entities must correct the error and resubmit the interchange file.

2. 999 – Functional Group Acknowledgement

After the interchange passes the TA1 edits, the next stage of editing is to apply TR3 edits and verify the syntactical correctness of the functional group(s) (GS/GE). Functional groups allow for organization of like data within an interchange; therefore, more than one (1) functional group with multiple claims within the functional group can be populated in a file. The 999 acknowledgement report provides information on the validation of the GS/GE functional group(s) and the consistency of the data. The 999 report provides MA organizations and other entities with information on whether the functional groups were accepted or rejected.

If a file has multiple GS/GE segments and errors occurred at any point within one of the syntactical and TR3 level edit validations, the GS/GE segment will reject, and processing will continue to the next GS/GE segment. For instance, if a file is submitted with three (3) functional groups and there are errors in the second functional, the first functional group will accept, the second functional group will reject, and processing will continue to the third functional group.

The 999 transaction set is designed to report on adherence to TR3 level edits and CMS standard syntax errors as depicted in the CMS edit spreadsheet. Three (3) acknowledgement values are:

• “A” – Accepted

• “R” – Rejected

• “P” – Partially Accepted, At Least One Transaction Set Was Rejected

When viewing the 999 report, MA organizations and other entities should navigate to the IK5 and AK9 segments. If an “A” is displayed in the IK5 and AK9 segments, the claim file is accepted and will continue processing. If an “R” is displayed in the IK5 and AK9 segments, an IK3 and an IK4 segment will be displayed. These segments indicate what loops and segments contain the error that needs correcting so the interchange can be resubmitted. The third element in the IK3 segment identifies the loop that contains the error. The first element in the IK3 and IK4 indicates the segment and element that contains the error. The third element in the IK4 segment indicates the reason code for the error.

3. Dental Validation Report

After the file is accepted at the interchange and functional group levels, the third type of report MA organizations will receive is a Dental Validation report. If an encounter is accepted, the Dental Validation report will provide the ICN assigned to that encounter.

4. Reports File Naming Conventions

For MA organizations and other entities to receive and identify the EDFES acknowledge reports (TA1, 999, and Dental Validation report) specific report file naming conventions have been used. The file name ensures that the specific reports are appropriately distributed to each secure, unique mailbox. The EDFES has established unique file naming conventions for reports distributed during testing and production.

Table 7A below provides a description of the SFTP file name components, which will assist MA organizations and other entities in identifying the report type.

TABLE 7A – EDFES REPORTS FILE NAMING CONVENTIONS

REPORT TYPE	SFTP MAILBOX
RSPnnnnn	The type of data ‘RSP’ and a sequential number assigned by the server ‘nnnnn’
X12nnnnn	The type of data ‘X12’ and a sequential number assigned by the server ‘nnnnn’
TMMDDCCYYHHMMS	The Date and Time stamp the file was processed
999nnnnn	The type of data ‘999’ and a sequential number assigned by the server ‘nnnnn’
RPTnnnnn	The type of data ‘RPT’ and a sequential number assigned by the server ‘nnnnn’

1. Testing Reports File Naming Convention

Table 7B below provides the EDFES report file naming conventions according to connectivity method. MA organizations and other entities should note that NDM/Connect:Direct users’ report file naming conventions are user defined.

TABLE 7B – SFTP TESTING EDFES REPORTS FILE NAMING CONVENTIONS

REPORT TYPE	CMS MFT/SFTP MAILBOX	SFTP MAILBOX
EDFES Notifications	T.nnnnn.MCD_RESPONSE.pn	INVCCYYMMDDHHMMSSSSS.INV
TA1	T.nnnnn.MCD_REJT_IC_ISAIEA.pn	<Submitter ID>.CCYYMMDD.THHMMSS.nnnnnn.s.TA1
999	T.nnnnn.MCD_REJT_FUNCT_TRANS.pn	<Submitter ID>.CCYYMMDD.THHMMSS.nnnnnn.s.999
999	T.nnnnn.MCD_ACCPT_FUNCT_TRANS.pn	<Submitter ID>.CCYYMMDD.THHMMSS.nnnnnn.s.999
Validation Report	T.nnnnn.MCD_RESPONSE.pn	<Submitter ID>.CCYYMMDD.THHMMSS.nnnnnn.s.VALIDATION.RPT

2. Production Reports File Naming Convention

Different production report file naming conventions are used so that MA organizations and other entities may easily identify reports generated and distributed during production. Table 7C below provides the report file naming conventions per connectivity method for production reports.

TABLE 7C – SFTP PRODUCTION EDFES REPORTS FILE NAMING CONVENTIONS

REPORT TYPE	CMS MFT/SFTP MAILBOX	SFTP MAILBOX
EDFES Notifications	P.nnnnn.MCD_RESPONSE.pn	INVCCYYMMDDHHMMSSSSS.INV
TA1	P.nnnnn.MCD_REJT_IC_ISAIEA.pn	<Submitter ID>.CCYYMMDD.THHMMSS.nnnnnn.s.TA1
999	P.nnnnn.MCD_REJT_FUNCT_TRANS.pn	<Submitter ID>.CCYYMMDD.THHMMSS.nnnnnn.s.999
999	P.nnnnn.MCD_ACCPT_FUNCT_TRANS.pn	<Submitter ID>.CCYYMMDD.THHMMSS.nnnnnn.s.999
Validation Report	P.nnnnn.MCD_RESPONSE.pn	<Submitter ID>.CCYYMMDD.THHMMSS.nnnnnn.s.VALIDATION.RPT

7. MA Supplemental Dental Testing and Certification

MA organizations will be required to submit test files to ensure the submitter’s systems are properly configured for data submission. Before exchanging production transactions, each plan must complete testing to become certified. This process allows MA organizations to confirm that the CMS operational guidance has been properly programmed in their systems. (Note: MA organizations must first enroll to submit MA organization data before any testing occurs.)

MEDICARE ADVANTAGE SUPPLEMENTAL DENTAL TESTING/CERTIFICATION
All Plans (Medicare Advantage, Cost, PACE) and Third-Party Submitters	1 file containing a minimum of 25 encounters
Submission Requirements: Files must be identified using the Authorization Information Qualifier data element “Additional Data Identification” in the ISA segment (ISA01 = 03). Files must be identified using the Authorization Information data element to identify the “Test Certification File” in the ISA segment (ISA02 = TSTCERTFIL). Files must be identified as “Test” in the ISA segment (ISA15 = T). All files must pass with 100% acceptance rate. In the event more than the required number of encounters are submitted, the file must still receive a 100% acceptance rate.

8. Acronyms

The Acronym Table below outlines a list of acronyms that are currently used in documentation, materials, and reports distributed to MA organizations and other entities. This list is not all-inclusive and should be considered a living document; as acronyms will be added, as required.

ACRONYMS

ACRONYM	DEFINITION
C
CMS	Centers for Medicare & Medicaid Services
CRLF	Carriage Return Line Feed
CSSC	Customer Service and Support Center
E
EDFES	Encounter Data Front-End System
EDI	Electronic Data Interchange
EDR	Encounter Data Record
G
GDG	Generated Data Group
I
ICN	Interchange Control Number
L
LF	Line Feed
M
MA	Medicare Advantage
MASDS	Medicare Advantage Supplemental Dental Services
MBI	Medicare Beneficiary Identifier
P
PACE	Programs of All-Inclusive Care for the Elderly
S
SFTP	Secure File Transfer Protocol
T
TR3	ASC X12 Technical Report Type 3

REVISION HISTORY

VERSION	DATE	DESCRIPTION OF REVISION
1.0	2/7/2024	Baseline Version
1.1	2/12/2024	Updated with DPAP comments

1 Final 2009 inpatient prospective payment system (IPPS) rule, 73 Fed. Reg. 48434 (August 19, 2008). 

February 2024

3