Technical Instructions

This technical instruction defines, specifies, and differentiates T-MSIS data elements related to select beneficiary cost sharing information (i.e., copayment, coinsurance, and deductible data). States have varied interpretations of related T-MSIS beneficiary data elements. Consistent reporting allows for accurate interpretation of the data and decreases the administrative burden placed on states and CMS to validate the data.

This technical instruction applies to Medicaid and CHIP fee-for-service (FFS) claims and managed care encounters.

Accurate payment information, including beneficiary liability and payment amounts, is critical to support Medicaid and CHIP program integrity, oversight, and administration. This information is used to ensure that Medicaid and CHIP payments to the provider^[1] do not exceed the Medicaid or CHIP allowed amount^[2] and to evaluate the impact of beneficiary cost sharing liabilities and payments. Accurate reporting of a beneficiary’s financial liability and their actual out of pocket payments is important to safeguard Medicaid beneficiaries and is necessary to evaluate the impact of cost sharing policies on Medicaid expenditures, provider reimbursement, and beneficiary medical service utilization and outcomes.

Beneficiary cost sharing is the portion of the Medicaid or CHIP allowed amount the beneficiary pays to the provider for covered services, usually in the form of a copayment, coinsurance, or deductible. An important yet often overlooked aspect of beneficiary cost sharing is the difference between the amount the beneficiary is liable for and the amount the beneficiary pays. In general, a beneficiary (or their representative) is required to pay their entire cost sharing liability amount. The exceptions to the requirement – i.e., that the beneficiary pay their cost sharing liability in full -- are when a provider decides, on a beneficiary-by-beneficiary basis, to waive all or part of the beneficiary’s obligation to pay their cost sharing liability.

Individual income spend-down is not defined as a type of beneficiary cost sharing. Income spend-down is related to the amount an individual must reduce their income by paying for qualified expenses to become eligible for Medicaid coverage^[3]. On the other hand, beneficiary cost sharing “means any copayment, coinsurance, deductible, or other similar charge”^[4] related to the beneficiary’s portion of a claim’s Medicaid or CHIP allowed amount that the beneficiary must pay for the covered services.

The Social Security Act section 1902(a)(14) allows states to impose copayments, coinsurance, deductibles, and other similar charges for which beneficiaries are liable for on many Medicaid-covered benefits. While a provider can waive^[5] a beneficiary’s cost sharing liability, they can only do so on a case-by-case basis. In accordance with the Anti-Kickback Statute^[6] and False Claims Act^[7] providers are prohibited from routine copayment waivers that are designed to induce additional business.

In accordance with the Social Security Act Section 1903(r)(1)(F)^[8], states are required to submit beneficiary cost sharing data through T-MSIS to ensure necessary program integrity, program oversight, and administration. Further, states must provide upstream instructions to ensure providers, programs, and other claim submitting entities accurately report the information.

Consistency, reliability, and availability of T-MSIS beneficiary cost sharing data elements varies across states. The causes of these issues stem from several challenges:

1. Varying interpretations. States encounter difficulties with consistent interpretation and differentiation among key data elements. For example, states have struggled with determining when to report beneficiary copayment payment amounts in the Total Copayment Amount data element (deprecated as of T-MSIS Data Dictionary V3.0.0) versus the Beneficiary Copayment Amount data element (renamed BENEFICIARY-COPAYMENT-PAID-AMOUNT as of T-MSIS Data Dictionary V3.0.0). States also have had varying interpretations of the Copayment Waived Indicator data element, for which some states are reporting administrative level waivers (e.g., a Medicaid program that waives the copayment) rather than provider level waivers.
2. Missing information. Some claims do not contain the information required for T-MSIS reporting. For example, not all claims determine and/or report copayment amounts at the service line, but T-MSIS requires line and header level copayment amounts. Additionally, while T-MSIS collects copayment and coinsurance payment amounts separately, only the combined cost sharing payment amounts are available for some claims —i.e., the claim only contains the sum of the beneficiary copayment, coinsurance, and deductible payment amounts.
3. Differentiating liability from payment amounts. For T-MSIS reporting, some states do not differentiate between the cost sharing liability amounts from the paid amounts and report the beneficiary liability amount in data elements defined as beneficiary payment amounts.

These T-MSIS technical instructions are designed to address the challenges states face when reporting beneficiary cost sharing liable amounts, payment amounts, and instances of provider copayment waivers.

Beginning with T-MSIS Data Dictionary V3.0.0, T-MSIS will collect one header-level beneficiary copayment paid amount: TOT-BENEFICIARY-COPAYMENT-PAID-AMOUNT (CIP208, CLT155, COT132, CRX089) across all claim file types. T-MSIS will no longer collect the TOT-COPAY-AMT data element (CIP115, CLT066, COT051, CRX042—deprecated as of T-MSIS Data Dictionary V3.0.0).

A beneficiary's cost sharing liability amount is the amount the beneficiary is obligated to pay for covered services on a claim. The beneficiary’s cost sharing liability is determined by the State Medicaid or CHIP agency or the managed care organization (MCO) negotiated contract and is the amount the beneficiary is obligated to pay to the provider (i.e., the amount they are liable to pay) toward the allowed amount in the form of a copayment, coinsurance, and/or deductible for covered services on a claim.

There are three data elements that report beneficiary cost sharing liability amounts (all new as of T-MSIS Data Dictionary V3.0.0): TOT-BENEFICIARY-COPAYMENT-LIABLE-AMOUNT (CIP192, CLT239, COT230, CRX163), TOT-BENEFICIARY-COINSURANCE-LIABLE-AMOUNT (CIP293, CLT240, COT231, CRX164), and TOT-BENEFICIARY-DEDUCTIBLE-LIABLE-AMOUNT (CIP294, CLT241, COT232, CRX165).

• States should report the amount the beneficiary is liable to pay towards the allowed amount for the Medicaid or CHIP covered services on the claim, i.e., the beneficiary’s copayment liability, coinsurance liability and deductible liability.
• States should not subtract any payments or discounts that went toward the beneficiary cost sharing liability.
• States should not subtract third party liability toward the beneficiary cost sharing liability.
• States should not subtract beneficiary cost sharing waivers or discounts made by the provider.
• The deductible liability amount should account for previous deductible payments made by the beneficiary that went toward their Annual Deductible when reporting the deductible liability for the covered services on the claim.

A beneficiary’s cost sharing payment amount is the amount the beneficiary pays out of their own pocket toward their cost sharing liability. The beneficiary’s cost sharing liability is determined by Medicaid or the MCO negotiated contract and is the amount the beneficiary pays to the provider toward the allowed amount in the form of a copayment, coinsurance, and/or deductible payment for covered services on a claim.

There are five data elements that report beneficiary cost sharing payment amounts (new or renamed as of T-MSIS Data Dictionary V3.0.0): TOT-BENEFICIARY-COPAYMENT-PAID-AMOUNT, BENEFICIARY-COPAYMENT-PAID-AMOUNT, TOT-BENEFICIARY-COINSURANCE-PAID-AMOUNT, TOT-BENEFICIARY-DEDUCTIBLE-PAID-AMOUNT, and COMB-BENEFICIARY-COST-SHARING-PAID-AMOUNT.

• States should separately report the beneficiary paid amount for each type of cost sharing, i.e., the beneficiary’s copayment, coinsurance, and deductible for covered services on a claim.
• For claims where states are unable to determine if the beneficiary paid amount went toward their copayment, coinsurance, or deductible (e.g., the copayment and coinsurance payment amounts are reported as one amount), states should report the Combined Beneficiary Cost Sharing Paid Amount only. In these instances, states should not report beneficiary payment amounts in the individual cost sharing data elements.
• States should include payments made by a beneficiary or their representative (e.g., their guardian).
• States should not include payment amounts made by liable third party/ies, even when these payments may reduce how much the beneficiary owes.
• States should not include waivers or discounts made by the provider.

There are situations where the amount a beneficiary must pay out of their own pocket toward their cost sharing liability is reduced. One such condition is when the provider of the covered services waives or discounts the beneficiary’s copayment liability.

The COPAY-WAIVED-IND data element in T-MSIS (new as of T-MSIS Data Dictionary V3.0.0) collects instances when the provider waives the beneficiary copayment.

These technical instructions outline best practice for reporting Medicaid-certified bed information for a provider in the T‐MSIS Provider file when the provider is a facility with types of beds that are represented by the T-MSIS bed type values.

States report data about a facility-provider’s Medicaid-certified beds on the T‐MSIS Provider (PRV) file PROV‐BED‐TYPE‐INFO (PRV00010) record segment, reported via the segment’s data elements, including BED‐TYPE‐CODE (PRV173), BED‐COUNT (PRV135), PROV-LOCATION-ID (PRV129), BED‐ TYPE‐EFF‐DATE (PRV130), and BED‐TYPE‐END‐DATE (PRV131). Each PRV00010 record segment represents a Medicaid-certified bed type and the number of that type of bed at the given facility provider location. The PRV00010 record segment is not required for providers that are not facilities with types of beds that are represented by the T-MSIS bed type values.

Some states have reported overlapping and redundant PRV00010 record segments. Sometimes this is because the state’s proprietary bed type classification system is more granular that the T-MSIS bed type categories. Sometimes this is the state is not properly maintaining historical changes in facility bed information.

States are also seeking guidance regarding which beds at a given facility they should report via the PRV00010 record segment.

Each PRV00010 record segment represents a Medicaid-certified bed type and the number of that type of bed at the given facility-provider location. A provider that is a facility with types of beds that are represented by the T-MSIS bed type values must have a PRV00010 record segment for each unique combination of SUBMITTING‐STATE, SUBMITTING‐STATE‐PROV‐ID, PROV‐LOCATION‐ID, and BED‐TYPE-CODE. The number of beds for each bed type should be reported on its own separate segment. If the value in one or more of the data elements in the PRV00010 record segment changes, a new record segment must be created, ensuring the two segments’ effective dates and end dates do not overlap.

States that submit a PRV file using a non-claims submission method that includes historical records should continue to report historical record segments in their submissions with information that is accurate for the date range for each segment according to segment effective and end dates (that is, the values accurately reflect the truth as it is understood to be at the time the record is created or updated). This ensures a full historical account of the facility provider’s beds are recorded in T‐MSIS.

Please see below for additional information on how to report each of the data elements in the PRV00010 record segment.

BED‐TYPE‐CODE is a data element used in T-MSIS to classify Medicaid‐certified beds at facilities, including Inpatient hospitals, Nursing Facilities, Intermediate Care Facilities for the Intellectually Disabled (ICF‐ID), Skilled Nursing Facilities (SNFs), and Institutions for Mental Disease (IMDs). If the provider is a facility, the bed types for the facility should be categorized into the T‐MSIS BED-TYPE-CODE valid values.^[1]

In many cases, a facility will have only one bed type. If a facility has only one bed type, then it should have one PRV00010 record segment with segment effective and end dates that span the duration the facility is enrolled with the state’s Medicaid program, or that span the duration for which the facility has only one bed type. In the case of facilities with multiple bed types, states should create multiple record segments—one for each bed type. As a provider changes bed designations over time, new records will need to be created to record the correct number of beds by type within the effective date and end date range for which the values in the segment were in effect.

In the event where a provider’s bed types are ambiguous, such as swing beds, the BED‐TYPE‐CODE should be reported based on the provider’s facility type, using the BED‐TYPE‐CODE valid values as a basis. If a facility has beds with types they consider more granular than the valid values for BED‐TYPE‐CODE, then these should be consolidated into one of the relevant valid values for BED‐TYPE‐CODE. There should be no more than one PRV00010 segment per bed type within a record segment’s effective date and end date range. This may mean that states need to combine more granular bed types into the T‐MSIS bed type valid values. For example, a hospital might have 150 acute care beds, 20 intensive care beds, 10 rehabilitation beds and 15 nursery/bassinet beds. These more granular bed types would be consolidated into one of the relevant valid values for BED‐TYPE‐CODE. Therefore, this facility would have one record segment with a BED‐TYPE‐CODE of ‘2’ (Inpatient), with a BED‐COUNT of ‘195’.

If states know the number of Medicare SNF beds, they should report that under BED-TYPE-CODE of ‘4’ (Title 18 Skilled Nursing Facility). States should not double‐count beds under two different bed types. For example, a state should not count beds reported as Medicare SNF beds in the Nursing Facility bed type as well. When the provider is a facility with beds, and the bed type is unknown, states should choose the most appropriate bed type (for example, hospitals would be coded to Inpatient [BED‐TYPE‐CODE of ‘2’] and nursing facilities to Nursing facility [BED‐TYPE‐CODE of ‘3’]).

For BED‐TYPE‐CODE, the value ‘8’ (Not Applicable) should not be used and has been removed from the T‐MSIS Data Dictionary. If the provider is not a facility, states do not need to report a PRV00010 record segment, making BED‐TYPE‐CODE of ‘8’ (Not Applicable) obsolete.

If the number of beds is unknown, states should space-fill BED‐COUNT, rather than report zero beds. If the provider is not a facility with types of beds that are represented by the T-MSIS bed type values and therefore the PRV00010 record segment is not applicable, states should not report this record segment for the provider and therefore should not report a zero value.

The BED‐TYPE‐EFF‐DATE and BED‐TYPE‐END‐DATE define the date spans for which the information for a unique PRV00010 record segment is applicable.

States should report the BED‐TYPE‐EFF‐DATE as the first day of the time span during which the values in all data elements in a unique PROV‐BED‐TYPE‐INFO record segment (defined as a unique combination of SUBMITTING-STATE, SUBMITTING-STATE-PROV-ID, PROV-LOCATION-ID, and BED-TYPE-CODE) are in effect (that is, the values accurately reflect reality as it is understood to be at the time the record is created).

States should report the BED‐TYPE‐END‐DATE as the last day of the time span during which the values in all data elements in a unique PROV‐BED‐TYPE‐INFO record segment are in effect (that is, the values accurately reflect the truth as it is understood to be at the time the record is created). If the BED‐TYPE‐END‐DATE is open ended (that is, the information in the segment is current with no known end date), it should be populated with 99991231 (December 31, 9999).

If the number of beds changes, then a new segment is reported. One segment includes the date range (effective date and end date) that applies to the previous number of beds, and the additional segment includes a date set that applies to the new number of beds. The only instance in which states need to change data on the record without starting a new date range is when the information is later determined to be inaccurate for the date range reported and the change represents a correction to the data.

Reporting BED‐TYPE‐EFF‐DATE and BED‐TYPE‐END‐DATE when the number of beds changes

CMS is introducing a new RESTRICTED-BENEFIT-CODE (ELG097) value to identify individuals dually eligible for Medicare/Medicaid who are enrolled in the Medicare Part B immunosuppressive drug (ID) benefit coverage.

In December 2020, the Consolidated Appropriations Act (CAA) of 2021^[1] was signed into law. It included a provision in Section 402 extending Medicare Part B coverage of immunosuppressive drugs for individuals who were eligible for Medicare solely because they had End-Stage Renal Disease (ESRD) that resulted in a kidney transplant covered by Medicare Part A in a Medicare-certified facility and whose 36 months of Medicare Part B coverage of immunosuppressive drugs had run out. This new benefit covers only immunosuppressive drugs and is referred to as the Medicare Part B-ID benefit. Before the CAA of 2021, individuals who were eligible for Medicare solely because of ESRD that resulted in a kidney transplant covered by Medicare Part A in a Medicare-certified facility were only eligible for Medicare Part B coverage of immunosuppressive drugs for 36 months after the month of the transplant.

Individuals are only eligible for Medicare Part B-ID benefit coverage if they do not have any other private insurance, Medicaid, or other public coverage of immunosuppressive drugs. As of the time of this publication, all states cover immunosuppressive drugs for beneficiaries with full Medicaid benefits. Therefore, the Medicare Part B-ID benefit only applies to persons with partial Medicare-Medicaid dual eligibility enrolled in a Medicare Savings Program (MSP). These beneficiaries are eligible for Medicaid to pay the Medicare premium and, if/when applicable, Medicare cost-sharing for the Part B-ID benefit^[2]. These beneficiaries must be reported to T-MSIS.

Because this is a new benefit, there is currently no way to identify it in T-MSIS.

CMS is introducing a new RESTRICTED-BENEFIT-CODE value ‘G’ to identify that an “Individual is eligible for Medicaid but only entitled to restricted benefits based on Medicare dual-eligibility status Medicare Part B-ID ESRD Benefit.” The value was added to the list of valid values on September 16, 2022 and can be used for ELIGIBILITY-DETERMINANTS-ELIGIBLE-ELG00005 segments with effective dates greater than or equal to January 1, 2023^[3].

When a beneficiary that is partial dual-eligible (MSP-only) beneficiary loses Medicare entitlement that was based on ESRD 36 months after the month of a successful kidney transplant and converts to an MSP Part B-ID after enrolling in Part B-ID, the state will need to take the following steps:

1. End-date the beneficiary’s existing ELIGIBILITY-DETERMINANTS record segment (i.e., the segment containing RESTRICTED-BENEFIT-CODE “1”or “3”), and
2. Add a new ELIGIBILITY-DETERMINANTS record segment that contains the new RESTRICTED-BENEFIT-CODE value of ‘G’ that identifies the beneficiary’s coverage as MSP Part B-ID.

MSP-only beneficiaries should be reported to T-MSIS with the appropriate DUAL-ELIGIBLE-CODE for partial Medicaid benefits^[4].

States may need to assign new identifier numbers (IDs) for their providers (provider IDs) or beneficiaries (MSIS IDs) for various reasons. Valid provider IDs and MSIS IDs are important for linking across and within the T-MSIS files, linking to other datasets, and analyzing Medicaid and CHIP data. These technical instructions outline the process and steps for reporting a change in provider IDs or MSIS IDs (i.e., the state assigned unique beneficiary ID) to T-MSIS. The last section of this document presents examples using a few real-world scenarios.

The T-MSIS dataset is critical to Medicaid and CHIP program monitoring, integrity, and analytics, and is used to support quality of care, beneficiary access and enrollment, and program improvement efforts. For various reasons, states may need to re-enumerate all or a subset of provider IDs or beneficiary IDs (MSIS IDs). Whenever a state re-enumerates provider IDs or MSIS IDs, they must ensure that the historical record of the old ID is properly archived and a relationship between the old and new ID is established and maintained in T-MSIS.

T-MSIS relies on several record segments and data elements to identify and link unique Medicaid providers and beneficiaries across files, including previously reported T-MSIS data. Such linkages allow T-MSIS to associate beneficiaries to providers and the services rendered by those providers. Prior to the implementation of the approach detailed in these technical instructions, states that have re-enumerated provider IDs or MSIS IDs were required to resubmit all previously submitted T-MSIS claims and non-claims data, replacing the old provider IDs or MSIS IDs with the new provider IDs or MSIS IDs. While the resubmission of all claims and non-claims files with the new ID values is an effective approach to ensure that T-MSIS can accurately associate beneficiaries to the providers, it is not a sustainable approach.

Ensuring the accuracy, consistency, and reconciliation of resubmitted claims and non-claims data requires a significant amount of effort from states and CMS. The resubmission approach is administratively burdensome and resource intensive for both states and CMS. For states it requires retrospectively updating previously submitted files with the new provider IDs or MSIS IDs, validating the accuracy and completeness of the updates, and submitting the updated files to T-MSIS. For CMS it requires the processing and managing of large amounts of duplicate data (i.e., the updated and previously submitted data), validating the accuracy and completeness of the resubmission, and working with states to resolve any errors. After consulting three states currently in the process of changing their provider IDs or MSIS IDs, and reviewing impacts of prior changes by other states, CMS has implemented an approach—detailed in this document—to minimize the administrative and resource burden associated with the resubmission of claims and non-claims files for re-enumerated provider IDs or MSIS IDs.

The approach detailed in this technical instruction document provides an alternative to resubmission of all T-MSIS claims and non-claims data when states re-enumerate provider IDs or MSIS IDs. This updated approach relies on the submission of a crosswalk of the new and old IDs in select file segments: PROV-IDENTIFIERS-PRV00005 for Provider ID changes and ELG-IDENTIFIERS-ELG00022 for MSIS ID changes. When this crosswalk is used, CMS no longer requires or recommends that states re-submit updated claims data solely for the purpose of retroactively changing provider IDs and MSIS IDs.

Any new provider or MSIS IDs reported in the claims or non-claims data without following these technical instructions will trigger data quality errors.

State actions detailed in these technical instructions include:

1. Notifying CMS of upcoming ID change;
2. Retaining complete history associated with the old IDs;
3. Reporting the new IDs and the ID crosswalk records; and
4. Choosing a non-claim file submission method.

The Federal System will retain and maintain old and new provider IDs and MSIS IDs (Step 5) and will use this information to link data associated with the old and new MSIS IDs for the purposes of analysis, reporting, and monitoring.

States should inform CMS of Provider ID or MSIS ID changes as soon as the state plans to change their enumeration schema, including information about when the implementation will occur. Early communication is key to prevent any unnecessary data quality errors.

States should contact their assigned T-MSIS point-of-contact to obtain the template for states to use to notify to CMS of an upcoming provider ID or MSIS ID change (see Table 1 for a screenshot of the template).

Table 1. Template for State to Use to Notify CMS of an Upcoming Provider ID or MSIS ID Change

States must notify CMS when a Large System Enhancement (LSE) occurs effecting provider IDs or MSIS IDs. CMS understands that some MSIS ID changes occur in state databases monthly and with low frequency. For example, a state may Merge multiple Medicaid IDs for a single beneficiary under a single MSIS ID, or Unmerge (disassociate beneficiaries), or apply a TCAM (when a beneficiary transitions between CHIP and Medicaid). For these low-occurrence Merge, Unmerge, and TCAM scenarios, states do not need to first notify CMS, but must follow the remaining instructions. Refer to the Technical Instructions for Reporting Eligible Identifiers in T-MSIS for a more complete description of Merge, Unmerge, and TCAM reasons for change.

States should carry over the complete history since cutover associated with the old provider ID or old MSIS ID to the new provider or MSIS ID in all the relevant segments (e.g., PROV-ATTRIBUTES-MAIN-PRV00002, PROV-LOCATION-AND-CONTACT-INFO-PRV00003, PROV-AFFILIATED-GROUPS-PRV00008, PRIMARY-DEMOGRAPHICS-ELIGIBILITY-ELG00002, VARIABLE-DEMOGRAPHICS-ELIGIBILITY-ELG00003, and ELIGIBILITY-DETERMINANTS-ELG00005).

Because each state system is different, these technical instructions do not detail how states should successfully retain the history of the old IDs. Specifically, states should:

1. Carry the provider information associated with the old Provider ID in all related record segments to the new Provider ID record segments 
2. Carry the beneficiary information associated with the old MSIS ID in all related record segments to the new MSIS ID record segments

States should report the new provider or MSIS IDs and report a new record segment that crosswalks the old ID to the new ID. The timing of when to submit ID changes to T-MSIS should align with when the state began reporting the new provider IDs or MSIS IDs on T-MSIS claims. Specifically, states should report the new IDs and crosswalk in the first reporting period after the state began reporting the new provider IDs or MSIS IDs on T-MSIS claims.

3a. Create Provider ID Crosswalk Segments (Old ID to New ID)

States should create and report a new PROV-IDENTIFIERS-PRV00005 segment that crosswalks the “old” to the "new” provider IDs. Specifically, states should:

1. Report the new provider ID in the SUBMITTING-STATE-PROV-ID data element and in the PROV-IDENTIFIER data element. 
2. Report the valid value ‘9’ in the PROV-IDENTIFIER-TYPE data element. Reporting a value of ‘9’ in the PROV-IDENTIFIER-TYPE data element informs the Federal System that the PROV-IDENTIFIERS-PRV00005 segment includes the provider ID crosswalk and signals the linkage between old and new provider IDs. In the PROV-IDENTIFIERS-PRV00005 segment with PROV-IDENTIFIER-TYPE = ‘9’ report the: 
   1. New provider ID in the SUBMITTING-STATE-PROV-ID data element and
   2. Old provider ID in the PROV-IDENTIFIER data element.
3. Ensure that the old provider ID effective date (PROV-IDENTIFIER-EFF-DATE) and end date (PROV-IDENTIFIER-END-DATE) in the PROV-IDENTIFIERS-PRV00005 segment are within the earliest effective date (PROV-ATTRIBUTES-EFF-DATE) and the latest end date (PROV-ATTRIBUTES-END-DATE) in the PROVIDER-MAIN-PRV00002 parent segment of the new provider record.

3b. Create Beneficiary (MSIS) ID Crosswalk Segments (Old ID to New ID)

States should create and report a new ELG-IDENTIFIERS-ELG00022 segment that crosswalks the “old” to the “new” MSIS-IDENTIFICATION-NUM value. Specifically, states should:

1. Report the new MSIS ID in the MSIS-IDENTIFICATION-NUM data element and in the ELIG-IDENTIFIER data element.
2. Report valid value ‘2’ in the ELG-IDENTIFIER-TYPE data element. Reporting a value of ‘2’ in the ELG-IDENTIFIER-TYPE data element informs the Federal System that the record includes the MSIS ID crosswalk and signals the linkage between old and new MSIS IDs. In the ELG-IDENTIFIERS-ELG00022 segment with ELG-IDENTIFIER-TYPE  = ‘2’ segment, report the:  
   1. New MSIS ID in the MSIS-IDENTIFICATION-NUM data element and
   2. Old MSIS ID in the ELIG-IDENTIFIER data element and
   3. REASON-FOR-CHANGE (LSE, MERGE, UNMERGE, TCAM). Refer to Reporting Eligible Identifiers in T-MSIS.
3. Ensure that the old MSIS ID effective date (ELG-IDENTIFIER-EFF-DATE) and end date (ELG-IDENTIFIER-END-DATE) in the ELIGIBLE-IDENTIFIER-ELG00022 segment are within the earliest effective date (PRIMARY-DEMOGRAPHIC-ELEMENT-EFF-DATE) and the latest end date (PRIMARY-DEMOGRAPHIC-ELEMENT-END-DATE) in the PRIMARY-DEMOGRAPHICS-ELIGIBILITY-ELG00002 parent segment of the new beneficiary record. Refer to CMS Guidance: Reporting Eligible Identifiers in T-MSIS.

While states may continue to use their declared submission method when reporting new Provider or MSIS IDs, CMS strongly encourages states make a temporary declaration change to the TFFR submission method for the reporting period when the ID changes are necessary due to a Large System Enhancement. CMS recommends TFFR in the case of LSE based on experience that this type of submission is less likely to result in loss of data and additional state actions to address.

4a. For Provider ID changes states may for any submission method:

1. For providers assigned a new ID:  Report all record segments with new SUBMITTING-STATE-PROV-ID when the state began reporting the new provider IDs on T-MSIS claims. Do not report any record segments with the old SUBMITTING-STATE-PROV-ID, other than in the PROV-IDENTIFIERS-PRV00005 segment where the old SUBMITTING-STATE-PROV-ID is now reported as a PROV-IDENTIFIER value only.
2. For providers not assigned a new ID: Continue to report all the record segments with their old (i.e., their existing) SUBMITTING-STATE-PROV-ID.

4b. For MSIS ID changes states may for any submission method:

1. For the beneficiaries assigned a new MSIS-IDENTIFICATION-NUM: report all the record segments with the new MSIS-IDENTIFICATION-NUM when the state began reporting the new MSIS IDs on T-MSIS claims. Do not report any record segment with the old MSIS-IDENTIFICATION-NUM value, other than the ELG-IDENTIFIERS-ELG00022 segment where the old MSIS-IDENTIFICATION-NUM is now reported as an ELG-IDENTIFIER value
2. For the beneficiaries not assigned a new MSIS ID: continue to report all the record segments with their old (i.e., existing) MSIS-IDENTIFICATION-NUM.

The Federal System will maintain the records for the old and new SUBMITTING-STATE-PROV-ID values and will use this information to link data associated with the old and new provider IDs for the purposes of analysis, reporting, and monitoring.

Five examples are provided: 1. All provider IDs are changed during a LSE; 2. A subset of provider IDs are changed during a LSE; 3. All beneficiary IDs are changed during a LSE; 4. A subset of beneficiary IDs are changed during a LSE; and 5. Beneficiary IDs change due to merge activities.

A state decides to assign new provider IDs during an LSE to all providers that have been reported to T-MSIS since MSIS/T-MSIS cutover. The state intends to report to T-MSIS the new provider IDs starting in the Jun-2022 reporting period.

1. State communicates to CMS in advance

Using the CMS provided template, the state notifies CMS of the intended provider ID change (i.e., changes to reported SUBMITTING-STATE-PROV-ID values) for all providers. This notice should be communicated to CMS as soon as the state is certain of its plans to change the IDs.

Table 2 illustrates the information that the state submitted, using the CMS template, to notify CMS of the upcoming change in provider IDs. This includes the reporting state, the data element that will be updated, the reporting period that the new IDs will be reported to T-MSIS, and for whom the new IDs are being assigned.

Table 2. State Notifies CMS - All Provider IDs Change During LSE

2. In the reporting period prior to introducing the new provider IDs, states report the old SUBMITTING-STATE-PROV ID values in all segments of their PRV submission

In the reporting period prior to the introduction of the provider ID change, May 2022 in this example, the state reports the old SUBMITTING-STATE-PROV-ID values in PRV00002 and in all other segments. Table 3 shows the PRV00005 segments only; all other segments and data elements should be reported as usual.

As Table 3 illustrates, in the reporting period prior to the introduction of the new provider IDs, the state reports the old provider ID values in the SUBMITTING-STATE-PROV-ID and in the PROV-IDENTIFIER columns.

Table 3. PRV00005 Segments in Reporting Period Prior to ID Change Introduced - All Provider IDs Changed During LSE

3. In the reporting period that the new provider IDs are introduced, states report the old and new provider ID crosswalk in their PRV submission

The state reports the new provider ID in the SUBMITTING-STATE-PROV-ID column illustrated in Table 4, and appropriately identifies the reported state and NPIs reported in the PROV-IDENTIFIER column by reporting a valid PROV-IDENTIFIER-TYPE value of ‘1’ and ‘2’, respectively (see rows with RECORD-NUMBER ‘201’, ‘202’ ‘204’, and ‘205’). The state also reports the crosswalk between the old and new provider IDs (see rows with RECORD-NUMBER ‘203’ and ‘206’). Here, the state reports a valid value ‘9’ in the PROV-IDENTIFIER-TYPE column to indicate the crosswalk and reports the new provider ID value in the SUBMITTING-STATE-PROV-ID column and the old provider ID value in the PROV-IDENTIFIER column.

Table 4. PRV00005 Segments in Reporting Period ID Change Introduced – All Provider IDs Change During LSE

The state also ensures old provider IDs reported as an old PROV-IDENTIFIER in the PROV-IDENTIFIERS-PRV00005 segment have reported effective dates (PROV-INDENTIFIER-EFF-DATE) and end dates (PROV-INDENTIFIER-END-DATE) within the earliest effective date (PROV-ATTRIBUTES-EFF-DATE) and the latest end date (PROV-ATTRIBUTES-END-DATE) reported in the corresponding PROV-ATTRIBUTES-MAIN-PRV00002 parent segment(s) of the new SUBMITTING-STATE-PROV-ID.

4. State chooses a PRV file submission method

The state submits the PRV file using the TFFR submission method in the reporting period when the new provider IDs are introduced (in this example, June 2022). In the PRV submission, the state reports all record segments with new SUBMITTING-STATE-PROV-ID. In the PROV-IDENTIFIERS-PRV00005 segment the state reports the old SUBMITTING-STATE-PROV-ID value as a PROV-IDENTIFIER value.

5. Federal System maintains the records with the old and new SUBMITTING-STATE-PROV-ID values.

Using an active flag and archive flag illustrated in Table 5, the Federal System will maintain the records for the old and new SUBMITTING-STATE-PROV-ID values. The Federal System will flag the record for the old SUBMITTING-STATE-PROV-ID value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to TRUE. The Federal System will flag the record for the new SUBMITTING-STATE-PROV-ID value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to FALSE. Once the record for the new SUBMITTING-STATE-PROV-ID is active, the state no longer needs to report the record for the old SUBMITTING-STATE-PROV-ID. The Federal System will use this information to link data associated with the old and new provider IDs for the purposes of analysis, reporting, and monitoring.

Table 5. Federal System Maintains Records with Old and New SUBMITTING-STATE-PROV-ID Values

A state decides to assign new provider IDs during an LSE to a subset of providers that have been reported to T-MSIS since MSIS/T-MSIS cutover. The state intends to report to T-MSIS the new provider IDs starting in the Jun-2022 reporting period.

1. State communicates to CMS in advance

Using the CMS provided template, the state notifies CMS of the intended provider ID change (i.e., changes to reported SUBMITTING-STATE-PROV-ID values) for a subset of providers. This notice should be communicated to CMS as soon as the state is certain of its plans to change the IDs.

Table 6 illustrates the information that the state submitted, using the CMS template, to notify CMS of the upcoming change in provider IDs. This includes the reporting state, the data element that will be updated, the reporting period that the new IDs will be reported to T-MSIS, and for whom the new IDs are being assigned.

Table 6. State Notifies CMS - Subset Provider IDs Change During LSE

2. In the reporting period prior to introducing the new provider IDs, states report the old SUBMITTING-STATE-PROV ID values in all segments of their PRV submission

In the reporting period prior to the introduction of the provider ID change, May 2022 in this example, the state reports the old SUBMITTING-STATE-PROV-ID values in PRV00002 and in all other segments. Table 7 shows the PRV00005 segments only; all other segments and data elements should be reported as usual.

As Table 7 illustrates, in the reporting period prior to the introduction of the new provider IDs, the state reports the old provider ID values in the SUBMITTING-STATE-PROV-ID and in the PROV-IDENTIFIER columns.

Table 7. PRV00005 Segments in Reporting Period Prior to ID Change Introduced - Subset of Provider IDs Changed During LSE

3. In the reporting period that the new provider IDs are introduced, states report the old and new provider ID crosswalk in their PRV submission

In the reporting period the ID changes are introduced, in this example June 2022, the state reports the new provider IDs and ID crosswalks for those providers assigned a new ID.

Table 8 illustrates the relevant data elements for the PROV-IDENTIFIERS-PRV00005 segment for two providers, only one of which the state has assigned a new provider ID (see rows with RECORD-NUMBER ‘204’, ‘205’, and ‘206’).

For the provider not assigned a new provider ID (see rows RECORD-NUMBER ‘101’ and ‘102’), the state reports the old (i.e., their existing) provider ID in the SUBMITTING-STATE-PROV-ID column and also in the PROV-IDENTIFIER column (see row with RECORD-NUMBER ‘101’). The state also appropriately identifies the state and NPI values reported in the PROV-IDENTIFIER column by reporting a valid value ‘1’ and ‘2’ in the PROV-IDENTIFIER-TYPE column, respectively (see rows with RECORD-NUMBER 101 and 102).

For the provider assigned a new provider ID (see rows with RECORD-NUMBER ‘204’, ‘205’, and ‘206’), the state reports the new provider ID in the SUBMITTING-STATE-PROV-ID column and the new provider ID in the PROV-IDENTIFIER column, along with a valid value of ‘1’ and ‘2’ in the PROV-IDENTIFIER-TYPE column (see rows with RECORD-NUMBER ‘204’ and ‘205’). The state also reports the crosswalk between the old and new provider ID (see row with RECORD-NUMBER ‘206’). Specifically, the state reports a valid value ‘9’ in the PROV-IDENTIFIER-TYPE column to indicate the crosswalk, and reports the new provider ID value in the SUBMITTING-STATE-PROV-ID column and reports the old provider ID value in the PROV-IDENTIFER.

Table 8. PRV00005 Segments in Reporting Period ID Change Introduced – Subset Provider IDs Change During LSE

The state also ensures old provider IDs reported as an old PROV-IDENTIFIER in the PROV-IDENTIFIERS-PRV00005 segment have reported effective dates (PROV-INDENTIFIER-EFF-DATE) and end dates (PROV-INDENTIFIER-END-DATE) within the earliest effective date (PROV-ATTRIBUTES-EFF-DATE) and the latest end date (PROV-ATTRIBUTES-END-DATE) reported in the corresponding PROV-ATTRIBUTES-MAIN-PRV00002 parent segment(s) of the new SUBMITTING-STATE-PROV-ID.

4. State chooses a PRV file submission method

The state submits the PRV file using the TFFR submission method in the reporting period when the new provider IDs are introduced (in this example, June 2022).

For the providers assigned a new ID, the state submitted PRV file reports all record segments with new SUBMITTING-STATE-PROV-ID. In the PROV-IDENTIFIERS-PRV00005 segment the state reports the old SUBMITTING-STATE-PROV-ID value as a PROV-IDENTIFIER value.

For the providers that were not assigned a new ID, the state submitted PRV file reported all record segments with the old (i.e., their existing) SUBMITTING-STATE-PROV-ID.

5. Federal System maintains the records with the old and new SUBMITTING-STATE-PROV- ID values.

Since only a subset of provider IDs were changed, there will be two approaches to maintaining the mix of changed and unchanged IDs.

Using an active flag and archive flag for the old SUBMITTING-STATE-PROV-ID that was not changed, the record for the old SUBMITTING-STATE-PROV-ID will remain active, as long as the state continues to maintain it. This is illustrated in Table 9.

For the old and new SUBMITTING-STATE-PROV-ID values that have a crosswalk, the Federal System will maintain the records for the old and new SUBMITTING-STATE-PROV-ID values. The Federal System will flag the record for the old SUBMITTING-STATE-PROV-ID value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to TRUE. The Federal System will flag the record for the new SUBMITTING-STATE-PROV-ID value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to FALSE. Once the record for the new SUBMITTING-STATE-PROV-ID is active, the state no longer needs to report the record for the old SUBMITTING-STATE-PROV-ID. The Federal System will use this information to link data associated with the old and new provider IDs for the purposes of analysis, reporting, and monitoring.

Table 9. Federal System Maintains Records with Old and New SUBMITTING-STATE-PROV-ID Values

A state decides to assign new MSIS IDs during an LSE to all beneficiaries that have been reported to T-MSIS since MSIS/T-MSIS cutover. The state intends to report to T-MSIS the new MSIS IDs starting in the Jun-2022 reporting period.

1. State communicates to CMS in advance

Using the CMS provided template, the state notifies CMS of the intended MSIS ID change (i.e., changes to reported MSIS-IDENTIFICATION-NUM values) for all beneficiaries. This notice should be communicated to CMS as soon as the state is certain of its plans to change the IDs.

Table 10 illustrates the information that the state submitted, using the CMS template, to notify CMS of the upcoming change in MSIS IDs. This includes the reporting state, the data element that will be updated, the reporting period that the new IDs will be reported to T-MSIS, and for whom the new IDs are being assigned.

Table 10. State Notifies CMS - All MSIS IDs Change During LSE

2. In the reporting period prior to introducing the new MSIS IDs, states report the old MSIS-IDENTIFICATION-NUM values in all segments of their ELG submission

In the reporting period prior to the introduction of the MSIS ID change, May 2022 in this example, the state reports the old MSIS-IDENTIFICATION-NUM values in the ELIGIBLE-IDENTIFIER-ELG00022 (ELG00022) segment and in all other segments. Table 11 shows the ELG00022 segment only; all other segments and data elements should be reported as usual.

As Table 11 illustrates, in the reporting period prior to the introduction of the new MSIS IDs, the state reports the old MSIS ID values in the MSIS-IDENTIFICATION-NUM and in the ELG-IDENTIFIER columns. (As previously described, for the purposes of these technical instructions, an “old” MSIS ID refers to the “existing” MSIS ID that predates the assignment of the new MSIS IDs.)

Table 11. ELG00022 Segments in Reporting Period Prior to ID Change Introduced - All Beneficiary IDs Changed During LSE

3. In the reporting period the new beneficiary IDs are introduced, states report the new MSIS values and the ID crosswalk in the ELIGIBLE-IDENTIFIER-ELG00022 segments

In the reporting period the ID changes are introduced, in this example June 2022, the state reports the new IDs, and reports the crosswalk of the new MSIS IDs to the old MSIS IDs. Table 12 shows the ELG00022 segments only; all other segments and data elements should be reported as usual.

In the ELG00022 segment, the state reports the new MSIS ID in the MSIS-IDENTIFICATION-NUM-ID column and appropriately reports the same value (i.e., the new MSIS ID) in the ELG-IDENTIFIER column (see rows with RECORD-NUMBER ‘201’ and ‘204’). For these two records, the state reports a valid value ‘1’ in the ELG-IDENTIFIER-TYPE column to indicate the reported MSIS-IDENTIFICATION-NUM is the most current (or new) MSIS ID for that beneficiary.

The state also reports the crosswalk between the old and new MSIS IDs in the ELG00022 segment. For the crosswalk, the state reports a valid value ‘2’ in the ELG-IDENTIFIER-TYPE column to notify the Federal System that the record crosswalks the old MSIS ID to the new MSIS ID, reporting the new MSIS ID value in the MSIS-IDENTIFICATION-NUM column and the old MSIS ID value in the ELG-IDENTIFIER column (see rows with RECORD-NUMBER ‘203’ and ‘206’).

Table 12. ELG00022 Segments in Reporting Period ID Change Introduced – All Beneficiary IDs Change During LSE

The state also ensures old MSIS IDs reported as an old ELG-IDENTIFIER in the ELG00022 segment have reported effective dates (ELG-INDENTIFIER-EFF-DATE) and end dates (ELG-INDENTIFIER-END-DATE) within the earliest effective date (PRIMARY-DEMOGRAPHIC-ELEMENT-EFF-DATE) and the latest end date (PRIMARY-DEMOGRAPHIC-ELEMENT-END-DATE) reported in the corresponding PRIMARY-DEMOGRAPHICS-ELIGIBILITY-ELG00002 parent segment(s) of the new MSIS-IDENTIFICATION-NUM.

4. State chooses a ELG file submission method

The state submits the ELG file using the TFFR submission method in the reporting period when the new MSIS IDs are introduced (in this example, June 2022). In the ELG submission, the state reports all record segments with new MSIS-IDENTIFICATION-NUM. In the ELG-IDENTIFIERS-ELG00022 segment the state reports the old MSIS-IDENTIFICATION-NUM value as an ELG-IDENTIFIER value.

5. Federal System maintains the records with the old and new MSIS-IDENTIFICATION-NUM values.

Using an active flag and archive flag, the Federal System will maintain the records for the old and new MSIS-IDENTIFICATION-NUM values as illustrated in Table 13. The Federal System will flag the record for the old MSIS-IDENTIFICATION-NUM value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to TRUE. The Federal System will flag the record for the new MSIS-IDENTIFICATION-NUM value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to FALSE. Once the record for the new MSIS-IDENTIFICATION-NUM is active, the state no longer needs to report the record for the old MSIS-IDENTIFICATION-NUM. The Federal System will use this information to link data associated with the old and new MSIS IDs for the purposes of analysis, reporting, and monitoring.

Table 13. Federal System Maintains Records with Old and New MSIS-IDENTIFICATION-NUM Values

A state decides to assign new MSIS IDs during an LSE to a subset of beneficiaries that have been reported to T-MSIS since MSIS/T-MSIS cutover. The state intends to report to T-MSIS the new MSIS IDs starting in the Jun-2022 reporting period.

1. State communicates to CMS in advance

Using the CMS provided template, the state notifies CMS of the intended MSIS ID change (i.e., changes to MSIS-IDENTIFICATION-NUM values) for a subset of beneficiaries. This notice should be communicated to CMS as soon as the state is certain of its plans to change the IDs.

Table 14 illustrates the information that the state submitted, using the CMS template, to notify CMS of the upcoming change in MSIS IDs. This includes the reporting state, the data element that will be updated, the reporting period that the new IDs will be reported to T-MSIS, and for whom the new IDs are being assigned.

Table 14. State Notifies CMS – Subset of Beneficiary IDs Change During LSE

2. In the reporting period prior to introducing the new MSIS IDs, states report the old MSIS-IDENTIFICATION-NUM values in all segments of their ELG submission

In the reporting period prior to the introduction of the MSIS ID change, May 2022 in this example, the state reports the old MSIS-IDENTIFICATION-NUM values in the ELIGIBLE-IDENTIFIER-ELG00022 (ELG00022) segment and in all other segments. Table 15 shows the ELG00022 segment only; all other segments and data elements should be reported as usual.

As Table 15 illustrates, in the reporting period prior to the introduction of the new MSIS IDs, the state reports the old MSIS ID values in the MSIS-IDENTIFICATION-NUM and in the ELG-IDENTIFIER columns. (As previously described, for the purposes of these technical instructions, an “old” MSIS ID refers to the “existing” MSIS ID that predates the assignment of the new MSIS IDs.)

Table 15. ELG00022 Segments in Reporting Period Prior to ID Change Introduced – Subset of Beneficiary IDs Changed During LSE

3.  In the reporting period the new beneficiary IDs are introduced, states report the new MSIS values and the ID crosswalk in the ELIGIBLE-IDENTIFIER-ELG00022 segments

In the reporting period the ID changes are introduced, in this example June 2022, the state reports the new IDs for the subset of beneficiaries and reports the crosswalk of the new MSIS IDs to the old MSIS IDs. Table 16 shows the ELG00022 segment only; all other segments should be reported as usual.

For the beneficiary not assigned a new MSIS ID (see row with RECORD-NUMBER ‘101’), the state reports the old (i.e., their existing) MSIS ID in the MSIS-IDENTIFICATION-NUM-ID column and reports the same value in the ELG-IDENTIFIER column. The state appropriately reports a valid value ‘1’ in the ELG-IDENTIFIER-TYPE column to indicate that the ELG-IDENTIFIER value is the Medicaid Card ID (State MMIS) value.

For the beneficiary assigned a new MSIS ID (see rows RECORD-NUMBER ‘201’ and ‘202’), the state reports the new MSIS ID and the ID crosswalk. To report new MSIS ID, the state reports the new MSIS ID in the MSIS-IDENTIFICATION-NUM-ID column and reports the same value (i.e., the new MSIS ID) in the ELG-IDENTIFIER column (see row with RECORD-NUMBER ‘201’). The state appropriately reports a valid value ‘1’ in the ELG-IDENTIFIER-TYPE column to indicate that the ELG-IDENTIFIER value is the current (‘new’) Medicaid Card ID (State MMIS) value.

The state also reports the crosswalk between the old and new MSIS ID (RECORD-NUMBER 202). Specifically, the state reports a valid value ‘2’ in the ELG-IDENTIFIER-TYPE column to notify the Federal System that the record crosswalks the old MSIS ID to the new MSIS ID and reports the new MSIS ID value in the MSIS-IDENTIFICATION-NUM column and the old MSIS ID value in the ELG-IDENTIFIER column (see row with RECORD-NUMBER ‘202’).

Table 16. ELG00022 Segments in Reporting Period ID Change Introduced – Subset of Beneficiary IDs Change During LSE

The state also ensures old MSIS IDs reported as an old ELG-IDENTIFIER in the ELG00022 segment have reported effective dates (ELG-INDENTIFIER-EFF-DATE) and end dates (ELG-INDENTIFIER-END-DATE) within the earliest effective date (PRIMARY-DEMOGRAPHIC-ELEMENT-EFF-DATE) and the latest end date (PRIMARY-DEMOGRAPHIC-ELEMENT-END-DATE) reported in the corresponding PRIMARY-DEMOGRAPHICS-ELIGIBILITY-ELG00002 parent segment(s) of the new MSIS-IDENTIFICATION-NUM.

4.  State chooses a ELG file submission method

The state submits the ELG file using the TFFR submission method in the reporting period when the new MSIS IDs are introduced (in this example, June 2022).

For the beneficiaries assigned a new ID, the state submitted ELG file reports all record segments with new MSIS-IDENTIFICATION-NUM. In the ELG-IDENTIFIERS-ELG00022 segment the state reports the old MSIS-IDENTIFICATION-NUM value as an ELG-IDENTIFIER value.

For the beneficiaries that were not assigned a new ID, the state submitted ELG file reported all record segments with the old (i.e., the existing) MSIS-IDENTIFICATION-NUM.

5.  Federal System maintains the records with the old and new MSIS-IDENTIFICATION-NUM values

Using an active flag and archive flag for the old MSIS-IDENTIFICATION-NUM that was not changed, the record for the old MSIS-IDENTIFICATION-NUM will remain active as long as the state continues to maintain it as illustrated in Table 17.  For the old and new MSIS-IDENTIFICATION-NUM values that have a crosswalk, the Federal System will maintain the records for the old and new MSIS-IDENTIFICATION-NUM values. The Federal System will flag the record for the old MSIS-IDENTIFICATION-NUM value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to TRUE.  The Federal System will flag the record for the new MSIS-IDENTIFICATION-NUM value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to FALSE. Once the record for the new MSIS-IDENTIFICATION-NUM is active, the state no longer needs to report the record for the old MSIS-IDENTIFICATION-NUM.  The Federal System will use this information to link data associated with the old and new MSIS IDs for the purposes of analysis, reporting, and monitoring.

Table 17. Federal System Maintains Records with Old and New MSIS-IDENTIFICATION-NUM Values

On a monthly or periodic basis, a state assigns new MSIS IDs due to beneficiary Merge scenarios to a relatively small number of beneficiaries. The state intends to report to T-MSIS the new MSIS IDs starting in the Jun-2022 reporting period.

1.  State does not need to notify CMS in advance

The state does not need to notify CMS of MSIS ID changes due to Merge cases.  

2.  In the reporting period prior to introducing the new MSIS IDs, states report the old MSIS-IDENTIFICATION-NUM values in all segments of their ELG submission

In the reporting period prior to the introduction of the MSIS ID change, May 2022 in this example, the state reports the old MSIS-IDENTIFICATION-NUM values in the ELIGIBLE-IDENTIFIER-ELG00022 (ELG00022) segment and in all other segments. Table 18 shows the ELG00022 segment only; all other segments and data elements should be reported as usual.

As Table 18 illustrates, in the reporting period prior to merging two MSIS IDs, each MSIS ID is reported on a separate ELG00022 segment where the ELG-IDENTIFIER is equal to the MSIS-IDENTIFICATION-NUM and the ELG-IDENTIFIER-TYPE is equal to ‘1’.

Table 18. ELG00022 Segments in Reporting Period Prior to ID Change Introduced – Beneficiary ID Changed During Merge

3.    In the reporting period the new beneficiary IDs are introduced, states report the new MSIS values and the ID crosswalk in the ELIGIBLE-IDENTIFIER-ELG00022 segments

In the reporting period the IDs are merged, in this example June 2022, the state reports the crosswalk of the MSIS ID that belongs to the redundant record as the ELG-IDENTIFIER value associated with the MSIS-IDENTIFICATION-NUM value of the record the state will continue to maintain. Table 19 shows the ELG00022 segments only; all other segments and data elements should be reported as usual.

The state reports the crosswalk between the merged MSIS IDs. Specifically, the state reports a valid value ‘2’ in the ELG-IDENTIFIER-TYPE column to notify the Federal System that the segment crosswalks the MSIS ID that the state is no longer maintaining with the MSIS ID of the record that they continue to maintain (see row with RECORD-NUMBER ‘202’).

Table 19. ELG00022 Segments in Reporting Period ID Change Introduced – Beneficiary ID Changed During Merge

The state also ensures merged MSIS IDs reported as a MERGE ELG-IDENTIFIER in the ELG00022 segment have reported effective dates (ELG-INDENTIFIER-EFF-DATE) and end dates (ELG-INDENTIFIER-END-DATE) within the earliest effective date (PRIMARY-DEMOGRAPHIC-ELEMENT-EFF-DATE) and the latest end date (PRIMARY-DEMOGRAPHIC-ELEMENT-END-DATE) reported in the corresponding PRIMARY-DEMOGRAPHICS-ELIGIBILITY-ELG00002 parent segment(s) of the MSIS-IDENTIFICATION-NUM to which the MERGE ELG-IDENTIFIER has been merged.

4.  State chooses a ELG file submission method

The state submits the ELG file using their state declared method in the reporting period when the MSIS ID merge was introduced (in this example, June 2022). The state is not required to continue submitting the record for the MSIS-IDENTIFICATION-NUM that has been merged via the crosswalk.

5.  Federal System maintains the records with the old and new MSIS-IDENTIFICATION-NUM values

Using an active flag and archive flag, for the merged MSIS-IDENTIFICATION-NUM values that have a crosswalk, the Federal System will maintain the records for the both MSIS-IDENTIFICATION-NUM values as illustrated in Table 20. The Federal System will flag the record for the merged MSIS-IDENTIFICATION-NUM value with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to TRUE.  The Federal System will flag the record for the MSIS-IDENTIFICATION-NUM value that will continue to be maintained with the ACTIVE-FLAG equal to TRUE and the ARCHIVE-FLAG equal to FALSE. Once the records are merged, the state no longer needs to report the record for the merged MSIS-IDENTIFICATION-NUM.  

Table 20. Federal System Maintains Records with Old and New MSIS-IDENTIFICATION-NUM Values

This technical instructions document outlines the challenges states have faced in reporting complete, accurate, and consistent data for personal care services (PCS) and home health care services (HHCS) in Transformed Medicaid Statistical Information System (T-MSIS) records and provides clarification for reporting these data. The guidance in this document addresses reporting complete and accurate data on PCS and HHCS in the T-MSIS Other Claims (OT) file.

Medicaid services provided in home and community-based settings, of which PCS and HHCS are a key component, encompass a growing share of Medicaid’s long-term care spending. All states are expected to report PCS and HHCS data completely and accurately. Proper reporting of these data will help ensure the accurate interpretation of enrollment, utilization, and payment data for these services captured in T-MSIS.

PCS (also known in States by other names such as personal attendant services, personal assistance services, attendant care services, and so on) include a range of assistance that enables people to accomplish tasks that they would normally do themselves if they did not have a disability. Such tasks are called Activities of Daily Living (ADL) and Instrumental Activities of Daily Living (IADL).^[1] PCS typically includes activities such as bathing, dressing, toileting, laundry, and preparing meals that are provided by personal care attendants. Provision of PCS might allow individuals to retain independence and stay in their homes and states can offer PCS through various Medicaid authorities.^[2]

HHCS is care provided to individuals in a home setting rendered by medically trained professionals. It includes nursing services, home health aide services, as well as the distribution of medical supplies, equipment, and appliances suitable for use in any setting in which normal activities take place.   It may also include physical therapy, occupational therapy, and speech pathology and audiology services at the state’s option.

In December 2016, Section 12006 of the 21st Century CURES Act (114 U.S.C. 255) established electronic visit verification (EVV) requirements for PCS and for HHCS delivered under several Medicaid authorities. States must require EVV use for all Medicaid-funded PCS by January 1, 2020 and HHCS by January 1, 2023, although states with approved requests for Good Faith Effort Exemptions (GFE) had until January 1, 2021 for PCS and have  until January 1, 2024 to implement for HHCS.^[3] For both PCS and HHCS, states must electronically verify data on the type of service performed, the individual receiving the service, the individual providing the service, date of the service, start and ending time of the service, and location of service delivery. Data collected via an EVV should be appropriately mapped and reported to T-MSIS.

States face challenges in collecting complete and consistent PCS and HHCS data. Key data from PCS and HHCS claims that are frequently missing include dates of service and units of service provided. Some PCS providers do not have a National Provider Identifier (NPI), and therefore provider identifier numbers are also frequently missing from PCS and HHCS claims. States use a variety of different procedure codes and units of service for PCS claims, leading to a lack of consistency across these data elements within a state and across states. To address the administrative burden of enrolling each individual direct care provider and other challenges in reporting PCS and HHCS, CMS shared promising practices for states using EVV.^[4]

The guidance here clarifies reporting claims for beneficiaries receiving PCS and HHCS.

When reporting claims for PCS in T-MSIS, states should report all data available in their state systems for these services that can be mapped to T-MSIS by January 1, 2020. By January 1, 2023, this provision should include any HHCS data collected via EVV that can be mapped to T-MSIS (unless granted a GFE).  Although a standard list of procedure codes that corresponds to types of services provided as PCS or HHCS has not yet been established, reporting available data completely is a vital first step to establishing timely, accurate, and complete data that may be used for research purposes in the future. A list of relevant claim OT data elements that should be reported for PCS and HHCS claims, for both fee-for-service (FFS) claims and encounter records, and that align with the EVV requirements to go into effect January 1, 2020 for PCS and January 1, 2023 for HHCS, follows.

• MSIS-IDENTIFICATION-NUM: This identifies the individual receiving the service. The MSIS ID reported on the claim must correspond to an MSIS ID in the Eligible file, which contains eligibility characteristics that reflect whether any special authorities (other than the general optional Medicaid state plan benefit authority) were used to justify coverage of the claim, such as STATE-PLAN-OPTION-TYPE, WAIVER-TYPE, HCBS-CHRONIC-CONDITION-NON-HEALTH-HOME-CODE and so on.
• Dates of services including BEGINNING-DATE-OF-SERVICE and ENDING-DATE-OF-SERVICE: The date(s) the service was provided should be reported using these data elements.
• Service quantities including SERVICE-QUANTITY-ACTUAL, PRESCRIPTION-QUANTITY-ACTUAL (both formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL), SERVICE-QUANTITY-ALLOWED and PRESCRIPTION-QUANTITY-ALLOWED (both formerly known as OT-RX-CLAIM-QUANTITY-ALLOWED): The quantity or unit for the service, both the allowable and actual amounts, should be reported. In the case of PCS and HHCS the relevant unit is time, such as hours or some smaller increment of time (15-minute or half-hour increments).
• Provider Information, including SERVICING-PROV-NUM and BILLING-PROV-NUM: All providers should report this identifier, even those with an NPI. In cases where PCS providers do not have NPIs, another state-issued ID should be reported so the provider^[5] can be appropriately identified and associated with the PCS provided on the claim and linked to the provider file. Providers delivering PCS or HHCS should also have a corresponding record in the T-MSIS Provider file. For providers rendering PCS that do not have an NPI, the best classification match for his/her specialty type will likely be PROVIDER-CLASSIFICATION-TYPE “4” (Authorized Category of Service) with a PROVIDER-CLASSIFICATION-CODE of “51” (Personal Care Services). For providers rendering HHCS that do not have an NPI, the best classification match for his/her specialty type will likely be PROVIDER-CLASSIFICATION_TYPE “4” (Authorized Category of Service) with a PROVIDER-CLASSIFICATION-CODE best matching the type of HHCS they are providing (e.g., “016” Home health services - Nursing services). Providers with an NPI should use the taxonomy or taxonomies that the provider has self-assigned in NPPES that most accurately reflects the services they provide.
  • Providers not enrolled in Medicaid: For EVV providers rendering or billing for PCS or HHCS that are not enrolled in Medicaid, in T-MSIS we would expect that these providers should be reported in the T-MSIS Provider File with the information that is available, consistent with how other atypical providers are reported. It is anticipated that many of the EVV providers that are not enrolled in Medicaid are individuals. The information collected for these providers should be sufficient for tax reporting purposes (e.g., to populate a Form-1099-MISC) with basic identifying information such as name, address, and Social Security Number. The state should be able to further identify the individuals as a person who provides HHCS.
• PLACE-OF-SERVICE: Medicaid agencies and managed care organizations should not hard-code PLACE-OF-SERVICE values just for T-MSIS mapping purposes. PLACE-OF-SERVICE is a pass-through data element, meaning that the state should report the field in T-MSIS as reported by the provider or constructed by the EVV system.
• PROCEDURE-CODE: Although a standard list of procedure codes to use for PCS and HHCS has not yet been established, PCS and HHCS claims should report the Current Procedural Terminology (CPT) or Healthcare Common Procedural Coding System (HCPCS) procedure code used to adjudicate the claim.
• Service categorization: Table 1 displays all of the relevant data elements and valid values for PCS below. Table 2 displays all of the relevant data elements and valid values for HHCS below.
  • For PCS:
    • TYPE-OF-SERVICE: PCS should be reported with a TYPE-OF-SERVICE valid value of “051” (Personal care services) or “065” (HCBS  - Personal care services).
    • XIX-MBESCBES-CATEGORY-OF-SERVICE: “19A” (Home & Community-Based Services - Reg. Pay. (Waiver)), “19B” (Home & Community-Based Services - St. Plan 1915(i) Only Pay. ), “19C” (Home & Community-Based Services - St. Plan 1915(j) Only Pay), “19D” (Home & Community Based Services State Plan 1915(k) Community First Choice), “23A” (Personal Care Services - Reg. Payments), or “23B” (Personal Care Services - SDS 1915(j))^[6]
    • XXI-MBESCBES-CATEGORY-OF-SERVICE: “21” (Home and Community)^[7]
    • HCBS-TAXONOMY: “08030” (Personal Care)
    • BENEFIT-TYPE: PCS should be reported with a BENEFIT-TYPE valid value of “045” (Personal care services) (that is, State Plan PCS); “054” (Community First Choice); or “106” (Self-directed Personal Assistance Services under 1915(j)) depending on the beneficiary’s eligibility to receive PCS.
    • PROGRAM-TYPE: For individuals receiving PCS under
      • 1905(a)(24) State Plan PCS, the state should report a valid value of “00” (No Special Program)
      • Home and community-based care waiver, the state should report a valid value of “07”
      • 1915(i) Home and Community Based Services State Plan Option , the state should report a valid value of “13”
      • 1915(k) Community First Choice, the state should report a valid value of “11”
      • 1915(j) authority for self- directed personal assistance services or personal care under State Plan or 1915(c) waiver, the state should report a valid value of “16”
  • For HHCS:
    • TYPE-OF-SERVICE: HHCS should be reported with a TYPE-OF-SERVICE valid value of “016” (Home health services - Nursing services); “017” (Home health services - Home health aide service); “018” (Home health services - Medical supplies, equipment, and appliances suitable for use in the home); “019” (Home health services - Physical therapy provided by a home health agency or by a facility licensed by the State to provide medical rehabilitation services); “020” (Home health services - Occupational therapy provided by a home health agency or by a facility licensed by the State to provide medical rehabilitation services); “021” (Home health services - Speech pathology and audiology services provided by a home health agency or by a facility licensed by the State to provide medical rehabilitation services); or “064” (HCBS - Home health aide services).
    • XIX-MBESCBES-CATEGORY-OF-SERVICE: “12” (Home Health Services)
    • XXI-MBESCBES-CATEGORY-OF-SERVICE: “19” (Home Health)
    • HCBS-TAXONOMY: “08020” (Home Health Aide); “05010” (Private Duty Nursing); “05020” (Skilled Nursing); “11080” (Occupational Therapy); “11090” (Physical Therapy); “11100” (Speech, Hearing, and Language Therapy); “14031” (Equipment and Technology); “14032” (Supplies)
    • BENEFIT-TYPE: HHCS should be reported with a BENEFIT-TYPE valid value of “015” (Home Health Services - Intermittent or part-time nursing services provided by a home health agency); “016” (Home Health Services - Home Health Aide Services Provided by a Home Health Agency); “017” (Home Health Services - Medical supplies, equipment, and appliances suitable for use in the home); “22” (Home Health Services - Physical therapy; occupational therapy; speech pathology; audiology provided by a home health agency); “068” (Home Health Services - Home health aide services provided by a home health agency); or “076” (Home Health Aide) depending on the type of home health services the individual is authorized to receive.
    • PROGRAM-TYPE: For individuals receiving home health services under
      • 1905(a)(7) State Plan Home Health Services, the state should report a valid value of “00” (No Special Program)
      • Home and Community Based Waiver, the state should report a valid value of “07” (Home and Community Based Care Waiver Services)
• Billed and Payment Amounts: All relevant payment fields for the claim, such as TOT-MEDICAID-PAID-AMT and MEDICAID-PAID-AMT, should be reported with the correct billed and paid amounts. For additional information specific to populating these data elements for encounter records, please consult the CMS Technical Instruction: Reporting Paid and Billed Amounts on Managed Care Encounters in T-MSIS (see link below).

Table 1. Service categorization data elements and values for PCS reporting in T-MSIS

Table 2. Service categorization data elements and values for HHCS reporting in T-MSIS

Other T-MSIS Technical Instruction Topics to Reference

Please also see the following T-MSIS technical instruction topics for additional information on reporting guidance and instructions:

• CMS Technical Instructions: Best Practice for Reporting Waiver-Type and Waiver-Identifier in T-MSIS
• CMS Technical Instructions: Best Practice for Reporting SUBMITTING-STATE-PROVIDER-ID in the T-MSIS Provider File
• CMS Technical Instructions: Submitting Accurate and Complete Encounter Data
• CMS Technical Instructions: Reporting Place of Service in T-MSIS

This reporting reminder describes T-MSIS data elements that collect payments to providers for covered services on a claim. This reporting reminder is applicable to Medicaid and Children’s Health Insurance Program (CHIP) fee for service (FFS) claims and managed care encounters. It does not cover instances when the Medicaid agency or managed care plan pays towards a beneficiary’s Medicare coinsurance and deductible amounts (also called ‘cross-over’ claims).^[1]

• TOT-MEDICAID-PAID-AMT (CIP114, CLT065, COT050, CRX041)
  • MEDICAID-PAID-AMT (CIP254, CLT208, COT178, CRX125)
• TOT-BENEFICIARY-COPAYMENT-PAID-AMOUNT^[2](CIP208, CLT115, COT132, CRX089)
  • BENEFICIARY-COPAYMENT-PAID-AMOUNT^[2](COT176, CRX123)
• TOT-BENEFICIARY-COINSURANCE-PAID-AMOUNT^[2] (CIP206, CLT153, COT130, CRX087)
• TOT-BENEFICIARY-DEDUCTIBLE-PAID-AMOUNT^[2] (CIP210, CLT157, COT134, CRX092)
• COMBINED-BENE-COST-SHARING-PAID-AMOUNT^[2] (CIP295, CLT242, COT233, CRX166)
• TOT-TPL-AMT (CIP118, CLT069, COT054, CRX045)  
  • TPL-AMT (CIP253, CLT206, COT177, CRX124)
• TOT-OTHER-INSURANCE-AMT (CIP119, CLT070, COT056, CRX047)
  • OTHER-INSURANCE-AMT (CIP272, CLT207, COT213, CRX152)
• THIRD-PARTY-COPAYMENT-AMOUNT-PAID (CIP218, CLT165, COT142, CRX100)
• THIRD-PARTY-COINSURANCE-AMOUNT-PAID (CIP216, CLT163, COT140, CRX098)
• TOT-ALLOWED-AMT (CIP113, CLT064, COT049, CRX040)
  • ALLOWED-AMT (CIP252, CLT205, COT175, CRX122)

The T-MSIS data dictionary defines “Allowed Amount” as the maximum amount “determined by the payer as being 'allowable' under the provisions of the contract prior to the determination of actual payment.^[3]” There are situations where only one payer is liable for paying the provider, and other situations where multiple payers (e.g., the State Medicaid or CHIP Agency, hereby referred to as the state agency, a managed care organization (MCO), the beneficiary, Medicare, or a third party) are liable.  In T-MSIS, the Total Allowed Amount (TOT-ALLOWED-AMT: CIP113, CLT064, COT049, CRX040) data element collects the maximum amount, as determined by the state agency or MCO, that the provider will be paid for covered services on a Medicaid or CHIP claim.  Because Medicaid is, in general, the payer of last resort^[4], in the instances where there is a third party liable for services also covered by Medicaid, an accounting of the third-party liability (TPL) is used to determine how much of the Medicaid allowed amount, if any, remains due to the provider. If, after the Medicare liability and TPL is accounted for, a provider was paid less than the Medicaid-determined allowed amount, Medicaid pays the provider the Medicaid allowed amount minus the Medicare payment, TPL payment, and beneficiary cost sharing.
Currently, T-MSIS collects payment amounts made by the state agency or MCO, beneficiaries, Medicare, and third parties for covered services on a claim. Together, these payments to the provider (for the Medicaid or CHIP covered services on a claim) determine if the provider has been appropriately paid for the services provided to the beneficiary.

Total Medicaid (or CHIP) Payment is less than or equal to the Total Medicaid (or CHIP) Allowed Amount minus the sum of the Total Beneficiary Cost Sharing Payments and Total Third Party Payments for Medicaid (or CHIP) Covered Services.

If the Total Third Party Payment for Medicaid (or CHIP) covered services is greater than or equal to the Total Medicaid (or CHIP) Allowed Amount, then the Total Medicaid (or CHIP) Payment and Total Beneficiary Cost Sharing Payments should be zero.

Medicaid (or CHIP) payment (or, for encounter records, a managed care organization’s payment) to the provider for covered services is the amount that Medicaid (or CHIP) pays the provider for covered services on a claim. The amount Medicaid (or CHIP) pays is based on the Medicaid- (or CHIP-) determined allowed amount minus the beneficiary cost sharing and TPL payments. If the TPL payments for the Medicaid (or CHIP) covered services are equal to or exceed the Medicaid- (or CHIP-) determined allowed amount, the Medicaid (or CHIP) payment and Beneficiary cost sharing should be zero. 

The Total Medicaid Paid Amount (TOT-MEDICAID-PAID-AMT: CIP114, CLT065, COT050, CRX041) data element collects the total amount the state agency or MCO paid toward the Total Allowed Amount (TOT-ALLOWED-AMT: CIP113, CLT064, COT049, CRX040) for covered services on a claim.^[5]

Beneficiary cost sharing payments are the portion of the state agency or MCO determined allowed amount the beneficiary paid, and is usually in the form of a copayment, coinsurance, or payment towards a deductible. There may be instances where a beneficiary does not pay all or any of their liable amount. In such cases, the Total Medicaid (or CHIP) Allowed Amount may be greater than the sum of the amounts paid by the state agency or MCO, the TPL, and the beneficiary on a claim.

The Total Allowed Amount (TOT-ALLOWED-AMT: CIP113, CLT064, COT049, CRX040) data elements collect the Medicaid (or CHIP) allowed amounts on the entire claim. The Total Beneficiary Copayment Paid Amount (TOT-BENEFICIARY-COPAYMENT-PAID-AMOUNT:CIP208, CLT155, COT132, CRX089), Beneficiary Copayment Paid Amount (BENEFICIARY-COPAYMENT-PAID-AMOUNT: COT176, CRX123), Total Beneficiary Coinsurance Paid Amount (TOT-BENEFICIARY-COINSURANCE-PAID-AMOUNT: CIP206, CLT153, COT130, CRX087), and Total Beneficiary Deductible Paid Amount (TOT-BENEFICIARY-DEDUCTIBLE-PAID-AMOUNT: CIP210, CLT157, CLT157, CRX092) collect the respective copayment, coinsurance, and deductible amounts the beneficiary paid for covered services on a claim or claim line. The COMBINED-BENE-COST-SHARING-PAID-AMOUNT (CIP295, CLT242, COT233, CRX166) captures the combined amount paid by the beneficiary towards the copayment, coinsurance, and/or deductible payments when the claim does not differentiate among the payment types.

Third party payments^[6] refers to the amount the third party pays for covered services based on the TPL estimated allowed amount. In some instances, third-party allowed amounts (and therefore, payments) for Medicaid (or CHIP) covered services are less than the Medicaid- (or CHIP-) determined allowed amount; in other instances, third-party allowed amounts (and therefore, payments) are equal to or greater than the Medicaid- (or CHIP-) determined allowed amount. 

The Total Third Party Liability Amount (TOT-TPL-AMT: CIP118, CLT069, COT054, CRX045), Third Party Liability Amount (TPL-AMT: CIP253, CLT206, COT177, CRX124), Total Other Insurance Amount (TOT-OTHER-INSURANCE-AMT: CIP119, CLT070, COT056, CRX047), Other Insurance Amount (OTHER-INSURANCE-AMT: CIP272, CLT207, COT213, CRX152), Third Party Copayment Amount Paid (THIRD-PARTY-COPAYMENT-AMOUNT-PAID: CIP218, CLT165, COT142, CRX100), and Third Party Coinsurance Amount Paid (THIRD-PARTY-COINSURANCE-AMOUNT-PAID: CIP216, CLT163, COT140, CRX098) data elements collect the amounts the third party paid  for covered services.

Table 1. T-MSIS Data Elements Collecting Amounts Paid to a Provider for Covered Services

Complete and consistent state reporting of an individual’s eligibility status, including any changes, will be a critical component of CMS monitoring states’ transitions back to normal eligibility and enrollment operations in Medicaid and the Children’s Health Insurance Program (CHIP) after the end of the Public Health Emergency. This reporting reminder notes expectations for state reporting of ELIGIBILITY-CHANGE-REASON (ELG095) in the ELIGIBILITY-DETERMINANTS-ELG00005 segment of the T-MSIS Eligible File as well as an update to the definition of this data element.

ELIGIBILITY-CHANGE-REASON (ELG095)

ELIGIBILITY-CHANGE-REASON, which is on the ELIGIBILITY-DETERMINANTS-ELG00005 segment, should be populated when a change to an individual’s eligibility status results in a complete loss/termination of coverage. Using a default such as value ‘21’ (Unknown) or ‘22’ (Other) for all circumstances is not valid. Information about changes to an individual’s eligibility status should be identified using a state’s eligibility determination system. For example, if an individual qualified for Medicaid via Modified Adjusted Gross Income (MAGI) and now has excess income that no longer qualifies that individual for Medicaid, a value of ‘01’ (Excess income) should be reported in the ELIGIBILITY-CHANGE-REASON data element field on the individual’s last ELIGIBILITY-DETERMINANTS-ELG00005 segment containing the eligibility group that the beneficiary is no longer eligible for beyond the end date of the segment.

To clarify this reporting, CMS will update the T-MSIS Data Dictionary to include the following definition for ELIGIBILITY-CHANGE-REASON (ELG095)^[1] : The reason for a complete loss/termination in an individual's eligibility for Medicaid and CHIP. The end date of the segment in which the value is reported must represent the date that the complete loss/termination of Medicaid and CHIP eligibility occurred. The reason for the termination represents the reason that the segment in which it was reported was closed.

[1] For the most up-to-date T-MSIS Data Dictionary artifacts, users should refer to the T-MSIS Data Guide. 

This technical instructions document identifies the challenges states have faced when reporting payments by managed care plans to sub-capitated entities (referred to as “sub-capitation payments” below) for the management or provision of specific enrollee services as well as the associated encounter records for the services provided. The state T-MSIS technical instructions below explain how to report sub-capitation payments, the associated sub-capitated encounter records, and sub-capitated provider affiliation to T-MSIS, including the T-MSIS file to which they should be mapped and how key data elements should be populated.

States frequently contract with managed care plans to manage and ensure the delivery of care to Medicaid, Medicaid-expansion Children’s Health Insurance Program (M-CHIP), and separate Children’s Health Insurance Program (S-CHIP) program enrollees. In turn, these managed care plans can contract with other entities to facilitate the delivery of a specific set of services to a specific set of enrollees. These entities can include other managed care plans, administrative services organizations, subcontractors^[1], or network providers^[2]. These entities contracted with managed care plans are considered “sub-capitated entities” if they receive periodic payment regardless of the scope, duration, or volume of services a particular enrollee receives during the period covered by the payment (i.e., they are paid on an at-risk basis).

For example, a managed care plan could contract with a dental pre-paid ambulatory health plan (PAHP) and pay that PAHP a pre-defined sub-capitation payment for each person enrolled in the PAHP in a given month. Because the PAHP is at risk, the sub-capitation payment would be paid to the PAHP regardless of whether the enrollee received any services in that month.

In contrast, claim payments that managed care plans make to providers that are paid for each service rendered (e.g., fee-for-service payments) are not considered sub-capitated. For example, if a managed care plan contracts with a dental PAHP on a non-risk basis to provide services and the amount of the payment made by the managed care plan to the dental PAHP is always paid per-service, then the dental network is not considered a sub-capitated entity. Managed care plans may also establish agreements with network providers, either individuals or large organizations, to deliver services to beneficiaries in exchange for a periodic payment that is not directly contingent on the specific scope, duration, or volume of services provided to a particular beneficiary during the period covered by the payment (i.e., they are paid on an at-risk basis).

• The term “Medicaid and S-CHIP agencies” (see Figure 1) is used to mean either the unit or units of state government that administer(s) Medicaid and/or S-CHIP. Medicaid expansion CHIP (M-CHIP) is administered by the Medicaid agency. For the purposes of these technical instructions, the term ‘Medicaid’ will include M-CHIP, unless otherwise specified.
• The terms “managed care plan” (see Figure 1) and “MCP” are used to refer to the managed care plans that have a direct contract with the state Medicaid and/or S-CHIP agencies. In accordance with 42 CFR 438.2, managed care plan types include: comprehensive managed care organization (MCOs), prepaid inpatient health plans (PIHPs), prepaid ambulatory health plans (PAHPs), and primary care case management (PCCM) entities.
• Per 42 CFR 438.2, the term “network provider” (see Figure 1) means any provider, group of providers, or entity that has a network provider agreement with a MCO, PIHP, or PAHP, or a subcontractor, and receives Medicaid funding directly or indirectly to order, refer, or render covered services as a result of the state's contract with an MCO, PIHP, or PAHP. There are two types of network provider: 1) a capitated network provider and 2) a sub-capitated network provider. A capitated network provider is one that is not paid on a fee-for-service basis but is also not sub-contracted to the managed care plan because the managed care plan and the network provided are really one in the same. A sub-capitated network provider is sub-contracted to either a managed care plan or sub-capitated entity.
• The term “subcontractor” or “subcontracted entity” refers to an individual or entity that has a contract with an MCO, PIHP, PAHP, or PCCM entity that relates directly or indirectly to the performance of the MCO's, PIHP's, PAHP's, or PCCM entity's obligations under its contract with the State. A network provider is not a subcontractor by virtue of the network provider agreement with the MCO, PIHP, or PAHP. 
• The term “capitation payment” (see Figure 1) refers to the payments that state Medicaid or S-CHIP agencies make to managed care plans to cover contracted services. The term “sub-capitation payment” refers to the payment from the managed care plan to the sub-capitated entity or sub-capitated network provider to cover contracted services on an at-risk basis.
• There are two types of sub-capitated arrangements: 1) a sub-capitated entity arrangement and 2) a sub-capitated network provider arrangement.
  • “Sub-capitated entity” (see Figure 1) refers to an entity that the managed care plan contracts with to facilitate the delivery of and pay providers for contracted services in exchange for a sub-capitation payment. The sub-capitated entity uses the sub-capitation payments to reimburse rendering providers. Sub-capitated arrangements should generate managed care encounters; the sub-capitated entity must report the encounter data to the managed care plan so that the managed care plan can, in turn, report the sub-capitated encounter to the state Medicaid or S-CHIP agency. Because sub-capitated entities receive sub-capitated payments from managed care plans regardless of services rendered, the actual dollar value of the services on sub-capitated encounter records associated with a given enrollee will not necessarily equal the sub-capitation payment(s) for that enrollee. A sub-capitated entity is a type of “sub-contracted entity”.
  • “Sub-capitated network provider” (see Figure 1) refers specifically to a network provider that a managed care plan contracts with to render contracted services in exchange for a sub-capitation-payment. Because the sub-capitated network provider is the rendering provider, there would not be a fee-for-service payment amount to report on the service utilization records that become sub-capitated encounters when reported to the state Medicaid or S-CHIP agency by the managed care plan.
• The term “managed care encounter” refers to the information relating to the receipt of any items(s) or service(s) by an enrollee under a contract between a state and a MCP. There are two types of managed care encounters submitted to T-MSIS:
  • Capitated encounter records (see Figure 1) for which the rendering provider was paid on a fee-for-service basis by the managed care plan or an administrative-services only subcontractor of the managed care plan, and
  • Sub-capitated encounter records (see Figure 1) for which a sub-capitated entity was paid a sub-capitation payment from the managed care plan. This second type of encounter is one of the areas of focus of this guidance.
  • There are two types of sub-capitated encounter records:
    • Sub-capitated encounter records from providers who are paid by the sub-capitated entity on a fee-for-service basis (see Figure 1).
    • Sub-capitated encounter records from sub-capitated network providers (see Figure 1)

Figure 1. Payment and Data Relationships Between State Medicaid/S-CHIP Agency, [Network] Providers, Managed Care Plans, Sub-Capitated Entities, and Sub-capitated Network Providers

TOC = TYPE-OF-CLAIM
SL = SOURCE-LOCATION

States have faced challenges when attempting to report sub-capitation payments and the associated sub-capitated encounters in their T-MSIS files because there has been no way to distinguish between capitation payments versus sub-capitation payments and capitated encounters versus sub-capitated encounters. Sub-capitated arrangements make up an increasing share of services within Medicaid. States must report in T-MSIS files all services covered by their Medicaid program and S-CHIP, including those services (captured on sub-capitated encounters) paid for with sub-capitation payments.

Capitation payments from state Medicaid and S-CHIP agencies to their contracted managed care plans are directly matched by federal dollars, but dollars paid out by the managed care plan (both sub-capitation payments and FFS claim payments) are not. Therefore, failure to distinguish sub-capitation payments from managed care plans and capitation payments from state Medicaid and S-CHIP agencies in the T-MSIS submissions would cause Medicaid and S-CHIP expenditures to be overstated.^[3] As a result, only capitation payments from state Medicaid and S-CHIP agencies have historically been reported in T-MSIS to avoid any misinterpretation.

Likewise, states and T-MSIS data users have run into challenges with distinguishing between capitated encounter records and sub-capitated encounter records in T-MSIS. In particular, Medicaid and S-CHIP agencies have inquired about how to report to T-MSIS payment-related data elements on some types of sub-capitated encounter records, including payment-related reporting for sub-capitated network provider encounters.

The technical instructions below provide information on how sub-capitation payments and sub-capitated encounter records should be reported in T-MSIS. The first two sections detail the technical instructions on reporting sub-capitated encounter records for sub-capitated entities and sub-capitated network providers. The third section provides technical instructions on reporting sub-capitation payments. The fourth section provides technical instructions on reporting sub-capitated network provider information on the managed care file.

Sub-capitated encounter records collected by managed care plan from their sub-capitated entities should be reported to all applicable T-MSIS claims file types (i.e., CIP, CLT, COT, and CRX). Sub-capitated encounter records should be reported with the existing TYPE-OF-CLAIM (CIP100, CLT052, CRX029, COT037) valid values of “3” for Medicaid and Medicaid-expansion CHIP enrollees and TYPE-OF-CLAIM value of “C” for S-CHIP enrollees (see Table 1).

Table 1 - Sub-capitated Encounter Data Elements with Reporting Clarifications^[4]

The SOURCE-LOCATION (CIP104, CLT056, COT041, CRX032) field is used to distinguish between a provider who was ultimately paid by the managed care plan, a sub-capitated network provider, or any other sub-capitated entity. If the managed care plan pays a provider directly for Medicaid/S-CHIP enrollee’s service(s) on a FFS basis, then the SOURCE-LOCATION data element should be reported with a value of “20”. If the sub-capitated entity pays a provider for the Medicaid/S-CHIP enrollee’s service on a FFS basis, then the SOURCE-LOCATION data element should be reported with the new valid value of “22”. Accurately reporting the SOURCE-LOCATION data element allows data users to accurately identify which managed care encounters should be reported with payment information.

Finally, the PLAN-ID-NUMBER (CIP130, CLT080, COT066, CRX056) field on the sub-capitated encounter record should be reported with the managed care plan identifier for the managed care plan that issues the payment to the sub-capitated entity and contracts directly with the Medicaid or S-CHIP agency. All other data elements reported on sub-capitated encounter records should be reported consistently with the claims file reporting requirements noted in the data dictionary. If a field can be reported on a managed care encounter record, then the same information should be reported on a sub-capitated encounter record.

The compliance date for reporting sub-capitated encounter records from sub-capitated entities to T-MSIS is July 1, 2023.

In some situations, the sub-capitated entity is a network provider that provides services directly to an enrollee. In these cases, the sub-capitation payment directly covers the services for the enrollee and the sub-capitated entity does not pay for services on a fee-for-service basis. Under this scenario, the billed amount, the revenue charge amount, allowed amount, and the paid amount fields should all be reported with a null value and the SOURCE-LOCATION data element should be reported with the new valid value of “23”. TYPE-OF-CLAIM and PLAN-ID-NUMBER and all other data elements applicable to managed care encounters are treated the same for encounters from sub-capitated entities, sub-capitated network providers, and capitated network providers. Table 1 above summarizes the technical instructions for sub-capitated encounter record data elements that have updated reporting requirements for encounters from sub-capitated network providers.

The compliance date for reporting sub-capitated encounter records from sub-capitated network providers to T-MSIS is July 1, 2023.

As with capitation payments, sub-capitation payments should be reported on the “other type” (OT) of claim file within the CLAIM-HEADER-RECORD-OT-COT00002 segment, consistent with the reporting requirements identified in the T-MSIS data dictionary and the T-MSIS data dictionary appendices. Most data elements reported for sub-capitation payments should be populated in the same way they would be for a state-to-managed care plan capitation payment with the exception of the data elements identified in the following paragraphs and summarized in Table 2. This applies to sub-capitation payments made to sub-capitated entities and sub-capitated network providers.

Sub-capitation payment records should be reported with the new T-MSIS TYPE-OF-CLAIM (COT037) valid values that are used to capture financial transactions between a managed care plan and an entity that is not the state Medicaid or CHIP agency. These transactions include sub-capitation payments to sub-capitated entities and sub-capitated network providers. A state should report a valid value of “6” for sub-capitation payments for Medicaid or Medicaid-expansion CHIP beneficiaries enrolled in a managed care plan or “F” for sub-capitation payments for S-CHIP beneficiaries enrolled in a managed care plan^[5]. In addition, SOURCE-LOCATION (COT041) should be reported with a value of “20”. This value indicates that the source of the payment is the managed care plan.

When used in conjunction, these two values (TYPE-OF-CLAIM “6” and SOURCE-LOCATION “20” or TYPE-OF-CLAIM “F” and SOURCE-LOCATION “20”) uniquely identify that the record is a sub-capitation payment from the managed care plan to a sub-capitated entity or sub-capitated network providers. Uniquely identifying sub-capitation payments in this manner will allow end users to analyze these payments appropriately, including excluding the payments from any analysis of Medicaid/S-CHIP program expenditures. These sub-capitation payment records should not be reported with the existing TYPE-OF-CLAIM values of “2” or “B”, which should be used only for capitation payments from the state Medicaid or S-CHIP agency (respectively) to the managed care plan.

Additionally, the PLAN-ID-NUMBER (COT066) reported on the sub-capitation payment should be populated with the unique T-MSIS plan identifier for the managed care plan that is issuing or recouping the payment (and is contracted with the state Medicaid/S-CHIP agency). It is important that the sub-capitated entity or sub-capitated network providers with whom a managed care plan has a contract should not be identified as a managed care plan on the T-MSIS managed care file, as the Managed Care File only captures plans that contract directly with the Medicaid or CHIP agency. Instead, this entity or network provider should be identified as a provider on both the sub-capitation payment record and on the T-MSIS provider file. If the sub-capitated network provider does not have an NPI, then the entity should be documented in the same way that an atypical provider would be documented.

Finally, it is important that the appropriate T-MSIS TYPE-OF-SERVICE (COT186) valid value be reported on the claim line detail record for the sub-capitation payment. The existing TYPE-OF-SERVICE values used for Medicaid Managed Care capitation payments (i.e., 119, 120, 122) must be used to classify each sub-capitation payment as either a comprehensive managed care sub-capitation payment, a PIHP/PAHP sub-capitation payment, or a PCCM sub-capitation payment (or administrative fee), depending on the nature of the arrangement under which the sub-capitation payment was received by either the sub-capitated entity or the sub-capitated network provider. This represents the classification of the sub-capitation payment received by the sub-capitated entity or sub-capitated network providers, and not the capitation payment that the managed care plan received from the state.

Table 2 lays out a summary of key data elements for reporting sub-capitation payments in T-MSIS files. All other data elements reported on sub-capitation payment records should be reported consistently with the claims file reporting requirements noted in the data dictionary. If a field can be reported on a capitation payment record, then the same information should be reported on a sub-capitation payment record.

Table 2 - Sub-capitation Payment Data Elements with Reporting Clarifications^[6]

The compliance date established for reporting sub-capitation payments to T-MSIS has not yet been determined.

The relationship between the MCP and its sub-capitated network providers should be clearly identified on the T-MSIS provider file. A sub-capitated network provider should be uniquely identified on the PROV-AFFILIATED-PROGRAMS-PRV00009 segment of the provider file using AFFILIATED-PROGRAM-TYPE (PRV119) value of “6” to indicate that it is sub-capitated network provider and should be reported with the managed care plan ID that pays that network provider sub-capitation payments.

Each individual provider and facility that is owned or employed by the sub-capitated network provider should be reported with a PROV-AFFILIATED-GROUPS-PRV00008 segment to identify the relationship between the provider and the sub-capitated network provider. The SUBMITTING-STATE-PROV-ID of the PROV-AFFILIATED-GROUPS-PRV00008 segment would belong to the owned or employed provider and the SUBMITTING-STATE-PROV-ID-OF-AFFILIATED-ENTITY would belong to the sub-capitated network provider to show that each provider is owned or employed by the sub-capitated network provider.

For example, in table 3 below, the sub-capitated network provider Universal Health Providers (SUBMITTING-STATE-PROV-ID = 4) is a sub-capitated network provider with three employed providers, Dr. One, Dr. Two, and Dr. Three (SUBMITTING-STATE-PROV-ID = 1, 2, and 3 respectively). The three records for Dr. One, Dr. Two, and Dr. Three are reported with a SUBMITTING-STATE-PROV-ID (PRV109) value of “1”, “2”, and “3” on each respective record, and the SUBMITTING-STATE-PROV-ID-OF-AFFILIATED-ENTITY (PRV110) is populated with a value of “4” on all three records. These three records show that each of the three providers is employed by Universal Health Providers Network.

Sub-capitated network providers should otherwise be reported with the same types of information as those expected for providers that directly contract with a managed care plan that holds a contract with a state Medicaid or S-CHIP agency.

Table 3 - Affiliated Provider Group Reporting

The compliance date for identifying sub-capitated network providers on the provider file is July 1, 2023.

When applicable, states must be able to distinguish between capitation payments, capitated encounters, sub-capitation payments, and sub-capitated encounters in their T-MSIS file submissions so that CMS can properly interpret and analyze them, particularly the sub-capitation payments. To facilitate states’ ability to make this distinction, CMS is introducing two new TYPE-OF-CLAIM values to identify sub-capitation payments (‘6’ for Medicaid, ‘F’ for S-CHIP), two new SOURCE-LOCATION values to identify sub-capitated encounters (‘22’ if the provider was ultimately paid for the encounter by a sub-capitated entity, ‘23’ if the provider was ultimately paid for the encounter by a sub-capitated network provider), and one new AFFILIATED-PROGRAM-TYPE for sub-capitated network providers (‘6’). The compliance date for the instructions pertaining to sub-capitated encounter records and provider file data is July 1, 2023. The compliance date for the instructions pertaining to sub-capitation payments has not yet been determined.

This technical instruction document outlines the challenges states have faced when reporting quantity and unit of measure fields in the IP, LT, OT, and RX files and provides technical instructions to states on this topic.

Providers use a variety of formats to submit claims to state Medicaid (or CHIP) agencies or their managed care plans (such as UB-04 or the 837 forms). All types of claim formats have a field in the detailed claim lines where providers submit the quantity of procedure, service, or drug provided. Mapping the quantity of service from the claims forms to the detailed claim line fields is relatively straightforward in the IP and LT claims files, but mapping the quantity of service from the claim forms to the claim lines of the OT and RX files is not as clear. The unit of measure, which expresses the unit of measure for each corresponding value reported by the quantity data elements, can be populated on all claim types and should be populated when a given claim line also contains an NDC code. All claim lines that contain NDC codes, including all RX claim lines, should contain a unit of measure.

Many states are not mapping quantity of service from claims forms to T-MSIS claims files correctly because there are misunderstandings regarding the conditions under which the various variables listed in Table 1 should be populated. Some of these misunderstandings result from the various claim forms used to populate the claims files.

• Claims data in the T-MSIS IP and LT files come from the 837I/UB-04 claim formats.
• Claims data in the T-MSIS OT file come from the 837I/UB-04, the 837P/CMS-1500, the 837D/ADA 2012, and possibly other claim formats.
• Claims data in the T-MSIS RX files come from the NCPDP claim format.

In some situations, a single data element in the T-MSIS claims file will be mapped differently depending on the claim form being used to populate the claim record. For example, there are six or more fields from different claim formats that could be used to populate the same T-MSIS OT variable (SERVICE-QUANTITY-ACTUAL, formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL).

Additionally, it was not always clear how data elements should be populated. For example, the OT-RX-CLAIM-QUANTITY-ACTUAL field meant different things depending on whether it was in the OT file or the RX file.  In the RX file, the OT-RX-CLAIM-QUANTITY-ACTUAL data element mapped to the drug quantity when the drug is a prescription with an NDC, while in the OT file the same data element mapped to the service quantity. In addition, when the claim reported in the OT file is for a drug with an NDC code, the drug quantity should map to the NDC-QUANTITY data element and not to OT-RX-CLAIM-QUANTITY-ACTUAL.

All claims forms have a field used for reporting quantity in the detailed claim line segment in T-MSIS. In addition to the standard quantity values on the IP, LT, and OT files, when a NATIONAL-DRUG-CODE data element (CIP284, CLT228, COT217) is populated, then the corresponding NDC-QUANTITY data element (CIP278, CLT230, COT225) should be populated. The T-MSIS quantity and metric values which are populated will depend on whether the quantity value corresponds to a drug or a service.

• Procedures/Services
  • REVENUE-CENTER-QUANTITY-ACTUAL (formerly known as IP-LT-QUANTITY-OF-SERVICE-ACTUAL) (IP and LT files)
  • SERVICE-QUANTITY-ACTUAL (formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL) (when in the OT file)
• Drugs
  • NDC-QUANTITY (IP, LT, OT files when there is an NDC on a claim line)
  • PRESCRIPTION-QUANTITY-ACTUAL (formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL) (RX)
  • DTL-METRIC-DEC-QTY (RX)
  • NDC-UNIT-OF-MEASURE (IP, LT, OT files when there is an NDC on a claim line)
  • UNIT-OF-MEASURE (RX)

The quantity of service or procedure reported by providers on their claims should be mapped to the “actual” quantity fields in the T-MSIS IP, LT, and OT files. When a claim includes an NDC, regardless of the claim file, the quantity value reported with the NDC on the claim should map to the NDC-QUANTITY fields in the T-MSIS IP, LT, and OT files and the PRESCRIPTION-QUANTITY-ACTUAL (formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL) or DTL-METRIC-DEC-QTY in the RX file.

As mentioned earlier, before T-MSIS Data Dictionary V3.0.0 the OT-RX-CLAIM-QUANTITY-ACTUAL data element meant different things depending on if it is in the OT file or if it is in the RX file.  In V3.0.0, OT-RX-CLAIM-QUANTITY-ACTUAL was replaced by SERVICE-QUANTITY-ACTUAL in the OT file and PRESCRIPTION-QUANTITY-ACTUAL in the RX file. In the OT file, SERVICE-QUANTITY-ACTUAL should capture the “Units of Service/Days” (837I/UB-04) or “Units” (837P/CMS-1500, 837D/ADA 2012) fields, representing both revenue codes and procedure codes.  In the RX file PRESCRIPTION-QUANTITY-ACTUAL should capture the amount dispensed (“quantity dispensed” [NCDPD 442-E7] or “compound ingredient quantity” [NCDPD 448-ED]).

The T-MSIS data element DTL-METRIC-DEC-QTY captures quantity of compounds reported on an RX claim. The source of DTL-METRIC-DEC-QTY and PRESCRIPTION-QUANTITY-ACTUAL (formerly known as OT-RX-QUANTITY-ACTUAL) from a provider’s claim depends on whether the claim is for a compound drug or a non-compound drug.  If an RX claim is for a non-compound drug then DTL-METRIC-DEC-QTY is not applicable but PRESCRIPTION-QUANTITY-ACTUAL (formerly known as OT-RX-QUANTITY-ACTUAL) is applicable. If states report both PRESCRIPTION-QUANTITY-ACTUAL (formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL) and DTL-METRIC-DEC-QTY on the RX file, they should capture the same information.

The way that claims data are mapped from the source claim formats to T-MSIS should follow the conventions in Table 1. 

Table 1. Claim form source fields for populating quantity and unit of measure related data elements to the T-MSIS IP, LT, OT, and RX files

The T-MSIS data element UNIT-OF-MEASURE (CRX133) should be reported on all claim lines on the RX file, corresponding to the quantities reported by PRESCRIPTION-QUANTITY-ACTUAL (formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL) or DTL-METRIC-DEC-QTY. This element is mapped from two fields on the NCPDP claim form: field 600-28 UNIT OF MEASURE and field 451-EG COMPOUND DISPENSING UNIT FORM INDICATOR. Valid values for these two source fields use different codes to report the same underlying meaning, so they can be mapped to the common T-MSIS code set.  States should report values populated in the two NCPDP fields using the corresponding T-MSIS valid values. When a claim is a standard pharmacy claim, unit of measure should be reported from field 600-28 UNIT OF MEASURE. When a claim is a compound, unit of measure should be reported from field 451-EG COMPOUND DISPENSING UNIT FORM INDICATOR.

T-MSIS data elements NDC-UNIT-OF-MEASURE (CIP285, CLT229, or COT224) and NDC-QUANTITY (CIP278, CLT230, or COT225) are only applicable to and therefore reported in the IP, LT, and OT files when a value is reported to the NATIONAL-DRUG-CODE data element (CIP284, CLT228, or COT217). The data element NDC-UNIT-OF-MEASURE uses the same valid values and coding rules as UNIT-OF-MEASURE.

Valid values for units of measure

The data elements REVENUE-CENTER-QUANTITY-ALLOWED (formerly known as IP-LT-CLAIM-QUANTITY-ALLOWED), SERVICE-QUANTITY-ALLOWED, and PRESCRIPTION-QUANTITY-ALLOWED (both formerly known as OT-RX-CLAIM-QUANTITY-ALLOWED) reports the maximum quantity of service covered by Medicaid, CHIP, or the managed care plan that may be provided per day of service or per month.  Unlike REVENUE-CENTER-QUANTITY-ACTUAL (formerly known as IP-LT-CLAIM-QUANTITY-ACTUAL), SERVICE-QUANTITY-ACTUAL, and PRESCRIPTION-QUANTITY-ACTUAL (both formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL), which should be passed through directly from the providers claim to T-MSIS, REVENUE-CENTER-QUANTITY-ALLOWED (formerly known as IP-LT-CLAIM-QUANTITY-ALLOWED), SERVICE-QUANTITY-ALLOWED, and PRESCRIPTION-QUANTITY-ALLOWED (both formerly known as OT-RX-CLAIM-QUANTITY-ALLOWED) are expected to be calculated/assigned by the state or their managed care plans during claim adjudication.  On the RX file only, it is expected that PRESCRIPTION-QUANTITY-ALLOWED (formerly known as OT-RX-CLAIM-QUANTITY-ALLOWED) may not be frequently populated due to point-of-sale claim systems.  In this case, it is recommended that PRESCRIPTION-QUANTITY-ALLOWED (formerly known as OT-RX-CLAIM-QUANTITY-ALLOWED) is either not populated or is populated with the same value as PRESCRIPTION-QUANTITY-ACTUAL (formerly known as OT-RX-CLAIM-QUANTITY-ACTUAL).

As of June 24, 2022, with the release of the V3.0.0 of the Data Dictionary, the names of IP-LT-QUANTITY-OF-SERVICE-ACTUAL (CIP249 and CLT202) and IP-LT-QUANTITY-OF-SERVICE-ALLOWED (CIP250 and CLT203) were changed to REVENUE-CENTER-QUANTITY-ACTUAL and REVENUE-CENTER-QUANTITY-ALLOWED, and OT-RX-CLAIM-QUANTITY-ACTUAL (COT183, CRX132) and OT-RX-CLAIM-QUANTITY-ALLOWED (COT184, CRX131) changed to SERVICE-QUANTITY-ACTUAL and SERVICE-QUANTITY-ALLOWED on the OT file and PRESCRIPTION-QUANTITY-ACTUAL and PRESCRIPTION-QUANTITY-ALLOWED on the RX file.  The technical instructions in this document apply regardless of any changes in name to the data elements used to capture quantity. The changes to the data dictionary also align valid values of UNIT-OF-MEASURE (CRX133) with valid values from the source NCPDP claim form.

The accuracy and completeness of provider specialization information will be added as a T-MSIS priority issue in the spring of 2020. The ability to identify provider specialization in T-MSIS is vital for investigating a number of different research questions. For example, research on the geographic distribution of specialists is dependent on accurate and reliable provider specialty information. There is currently a lack of clarity with respect to which provider specialization identifiers should be used and how those identifiers should be reported. As a result, T-MSIS data on provider specialization is reported inconsistently across states. This technical instruction document provides clarification in this area.

The PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment captures information specific to provider specialization and authorization.  In that file segment, the value in the PROV-CLASSIFICATION-TYPE (PRV088) data element indicates which of four classification types the value in the PROV-CLASSIFICATION-CODE (PRV089) data element represents. The four PROV-CLASSIFICATION-TYPE (PRV088) code values are presented in Table 1.

Table 1: PROV-CLASSIFICATION-TYPE (PRV088) codes and descriptions (T-MSIS Data Dictionary version 2.3, [DATE])

All PROV-CLASSIFICATION-CODE values provided when PROV-CLASSIFICATION-TYPE  is set to 1 (Taxonomy code) must come from the Health Care Provider Taxonomy Code Set (includes external code lists maintained by X12 and external code lists maintained by others and distributed by WPC). All PROV-CLASSIFICATION-CODE values provided when PROV-CLASSIFICATION-TYPE is set to 2 (provider specialty), 3 (provider type), or 4 (authorized category of service) must correspond to values found in the T-MSIS Data Dictionary Appendix A.

When provider taxonomy, provider specialty, and provider type values are present in claims file segment data elements, there should be corresponding PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segments with matching values in the PROV-CLASSIFICATION-CODE (PRV089) data element.

The technical instructions below addresses which classification types should be supplied for a given provider, and whether states are permitted to use state-specific codes or if all PROV-CLASSIFICATION-CODE values should match standardized code sets. These topics are covered in detail below.

States have struggled to provide all four provider classification types for every provider.  To help states with this challenge, CMS will only require taxonomy codes (PROV-CLASSIFICATION-TYPE=1) for providers that have NPIs and Authorized Category of Service (PROV-CLASSIFICATION-TYPE=4) for providers that do not have NPIs.

Additionally, to clarify the alignment between values provided in the PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment and values provided in the claims data, this technical instruction document will provide mappings between PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment and data elements in the claims file segments.

Finally, several states are using state-specific code sets for reporting provider specialization.  Though states can continue to do this internally, the codes reported in T-MSIS must correspond to values provided by the National Uniform Claim Commission (NUCC) or the T-MSIS Data Dictionary Appendix A.  Consistency across states in this area is vital for any type of analysis using provider specialization.

The previously issued technical instructions instructed states that every provider was required to have at least one record segment in PROV-TAXONOMY-CLASSIFICATION (PRV00006) for every provider classification type, and to use the value “88” for the PROV-CLASSIFICATION-CODE when a given PROV-CLASSIFICATION-TYPE is not applicable.  The technical instructions provided here modifies that requirement and only require one classification type for any given provider.  Additionally, values of “88” should not be used unless it is part of the PROV-CLASSIFICATION-TYPE 1 – 4 code sets listed in T-MSIS Data Dictionary Appendix A. 

All providers in the PROV-ATTRIBUTES-MAIN (PRV00002) file segment are expected to have at least one code in the PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment. When necessary, a single provider can be assigned multiple codes for the same classification category. For example, a hand surgeon may be sub-classified under both orthopedics and plastic surgery, in which case they may have more than one provider taxonomy or specialty.

CMS has identified provider taxonomy (PROV-CLASSIFICATION-TYPE=1) as the preferred method of reporting provider specialization in T-MSIS.  Within the context of T-MSIS, the term provider taxonomy refers to the Health Care Provider Taxonomy Code Set maintained by the NUCC.  Using provider taxonomy to identify provider specialization has several advantages over the other provider classification codes sets:

• The Health Care Provider Taxonomy Code Set is nationally standardized and actively maintained by the NUCC. This means that the available provider taxonomy codes and their definitions should be consistent across states, and new taxonomy codes will be added as new provider specializations are introduced.
• The NUCC provider taxonomy codes can be very detailed and will provide enough granularity for most research purposes.
• Providers must supply a valid NUCC taxonomy code when they apply for a National Provider Identifier (NPI). As such, all providers with NPIs will have self-identified with at least one provider taxonomy code^[1]. 

Although all states are encouraged to adopt the NUCC provider taxonomy as a method to identify provider specialization, states that are not able to do so will not be penalized. Not all states use the NUCC provider taxonomy in their provider credentialing process, so the relationship between a provider and their taxonomy(s) will not always be available in some state Medicaid Management Information Systems.  States that provide documentation indicating their provider credentialing system does not use taxonomy codes will be permitted to use provider specialty (PROV-CLASSIFICATION-TYPE = 2) and provider type (PROV-CLASSIFICATION-TYPE = 3) codes instead of provider taxonomy.  If a state cannot provide a taxonomy code for a provider that has an NPI, and the provider specialty and provider type code lists do not contain a valid value for the provider (as is the case for dentists), states should use the authorized category of service code for the provider (PROV-CLASSIFICATION-TYPE = 4).  

Atypical providers that do not have NPIs, such as those that provide transportation or some home health services, may not have specializations that easily map to the taxonomy, specialty or provider type codes (PROV-CLASSIFICATION-TYPE = 1, 2, or 3).  For these providers, states should provide authorized category of service codes (PROV-CLASSIFICATION-TYPE = 4).   

Though only one PROV-CLASSIFICATION-CODE (PRV089) is required for each provider, states are encouraged to provide all available data. Providers that have more than one value for a given classification type (e.g., more than one taxonomy) and/or more than one classification type (e.g., a taxonomy and a specialty), will have multiple simultaneously active PROV‐TAXONOMY‐CLASSIFICATION‐PRV00006 record segments.

If a given provider’s specialization changes over time, retired entries should be end dated and new entries should be given appropriate start dates so that dates in the PROV-TAXONOMY-CLASSIFICATION file segment align with dates found in the claims data.

Any type of provider specialization analysis requires the availability of standardized specialization code sets that are consistent from one state to another. Therefore, all PROV-CLASSIFICATION-CODE (PRV089) values in the PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment must come from values provided on the X12 website, now hosting content from Washington Publishing Company (for taxonomy codes) or from values provided in the T-MSIS Data Dictionary Appendix A in tables specific to PROV-CLASSIFICATION-TYPE 2, 3, or 4.  State-specific provider specialization codes should not be used in the PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment or in the claims data. 

The codes provided in the claims data elements must have corresponding values in the PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment. Since there is no column to report authorized category of service code in any of the claims file segments, claims submitted by atypical providers are not expected to have taxonomy, specialty, or provider type values (though they can be reported if they are available).

The values provided in the claim file segments should come directly from the claims when they are submitted, values provided by managed care organizations, or values derived from NUCC taxonomy codes that came in on the claims.  States should not populate missing data elements on the claims file segments by mapping values from the PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment to the claims file segments.  This is to avoid complications that may arise in situations when a provider has more than one value for a given PROV-CLASSIFICATION-TYPE code in the PROV-TAXONOMY-CLASSIFICATION (PRV00006) file segment.  For example, if a paid claim was missing the taxonomy for the rendering provider and the rendering provider has more than one taxonomy in PROV-TAXONOMY-CLASSIFICATION (PRV00006) (e.g., a hand surgeon that sub-classifies under plastic surgery), it is not immediately obvious which taxonomy code should be populated on the claim.

The relationship between the codes provided in the PROV-TAXONOMY-CLASSIFICATION file segment and the claims file segments are outlined in Table 2.

Table 2: Relationships between Claims data elements and the PROV-CLASSIFICATION-TYPEs

As noted previously, non-missing values reported in the claims file segments must have corresponding entries in the PROV-TAXONOMY-CLASSIFICATION file segment.  Instances in which values do not match between file segments are an indication of incomplete or incorrect data. Future data quality evaluations may include checks that will flag such data inconsistencies.

Reporting complete claims classifier data elements is a T-MSIS Priority Item. This reporting reminder focuses on reporting claims classifier data elements: Type-of-Service, Type-of-Claim, Program-Type, CMS-64-Category-for-Federal-Reimbursement, and IHS-SERVICE-IND^[1] within the Claims files in T-MSIS.

• TYPE-OF-SERVICE (CIP257,CLT211,COT186, CRX134)
• TYPE-OF-CLAIM (CIP100, CLT052, COT037, CRX029)
• PROGRAM-TYPE (CIP129, CLT079, COT065, CRX055)
• CMS-64-CATEGORY-FOR-FEDERAL-REIMBURSEMENT (CIP269, CLT219, COT210, CRX149)
• IHS-SERVICE-IND (CIP296, CLT243, COT234, CRX172,)^[1]

T-MSIS includes data elements that help classify the services provided or the program and/or benefit under which the claim was covered. TYPE-OF-SERVICE, TYPE-OF-CLAIM, PROGRAM-TYPE, CMS-64-CATEGORY-FOR-FEDERAL-REIMBURSEMENT, and IHS-SERVICE-IND^[1] are data elements that help classify these services. These data elements are required and are applicable to all or nearly all claims in all file types. 

CMS will report a possible data quality issue when the following occur:

• There are more than a small percentage of claims for which TYPE-OF-SERVICE, TYPE-OF-CLAIM, or CMS-64-CATEGORY-FOR-FEDERAL-REIMBURSEMENT is missing; or
• The percentage of claims for which PROGRAM-TYPE equals 01 (EPSDT), 02 (Family Planning), or 04 (Federally Qualified Health Centers (FQHC)) are outside of a reasonable range.

Please refer to the T-MSIS data dictionary for specific coding requirements for each data element.

Records that void/reverse/cancel previously submitted FFS claims and encounters are important to accurately identify Medicaid utilization and expenditures. How the data elements are populated on these void/reversal/cancel records are important to accurately interpret the records. The following technical instruction document addresses how data elements should be populated in T-MSIS when a void/reversal/cancel record is included on the file.

Accurately reporting adjustments is necessary for identifying Medicaid and CHIP utilization and expenditures in T-MSIS. Completely and accurately populating data elements on void/reversal/cancel records allows for the records to be appropriately linked to the most recently submitted original/adjustment record^[1]. Additionally, consistent reporting across states allows for accurate interpretation of the data. This technical instruction document provides information on how to populate data elements on void/reversal/cancel records in T-MSIS. While this technical instruction document primarily addresses reporting void/reversal/cancel records for FFS claims and encounters, it also applies to capitation payments, supplemental payments or service tracking payments that are adjusted using replace and void/reversal/cancel processes. 

Some states do not currently follow the requirements for void/reversal/cancel records as specified in the T-MSIS data dictionary, particularly for reporting expenditures. States take various approaches for populating data elements in void/reversal/cancel records, leading to inconsistency in interstate comparisons, questions regarding the accuracy of the reporting, and potential inaccurate interpretations of the state’s data. Some states have raised questions about how to populate the dollar amount and quantity data elements on void/reversal/cancel records. While state Medicaid programs and MMIS may differ, it is important that states utilize uniform T-MSIS reporting methods where those opportunities exist.

States should report void/reversal/cancel records consistent with T-MSIS data dictionary requirements and appropriate technical instructions documents (see Related Technical Instructions). For the purposes of these technical instructions, the data elements reported on void/reversal/cancel records are grouped into four categories based upon how the data elements are populated by the state.

• Record Key data elements should be reported with values that uniquely identify the claim and link the void claim to the previously submitted original or adjustment claim or encounter.  These data elements are identified in Table 1. 
• X-12 transaction data elements should be reported with values related to the processing of the void claim.  These data elements are identified in Table 4. 
• Adjudicated quantity data elements should all be reported with a value of “0”. These data elements are identified in Table 5. 
• Carry Over data elements should be reported with values reported on the previous original or adjustment claim or encounter.  These represent all data elements not identified Table 1, Table 4 or Table 5.

Record key data elements are populated with information that uniquely identifies a record and links it to all other records in a claim family^[2]. The record keys are also used to link the information reported on the claim header to the claim line record. These data elements are reported in Table 1. All void/reversal/cancel records should be reported with ADJUSTMENT-IND and LINE-ADJUSTMENT-IND values of “1”. The other primary key data elements should be populated consistent with T-MSIS Data Dictionary and appendices. The adjudication date should be populated with the date on which payment status of the claim was finally adjudicated by the state, as per the T-MSIS data dictionary. The ICN-ORIG and ICN-ADJ data elements should be populated with values that link the void to the most recently submitted original/adjustment record in the claim family.

Table 2 provides examples of void claims linked to previous records using the original ICN approach (rows 1 – 3), and Table 3 provides examples of void claims linked to previous records using the daisy chain ICN approach (rows 4 - 6). Both examples represent a claim family where the original claim is first followed by an adjustment that corrects the value reported in the TOT-BILLED-AMT and then followed by a void/reversal/cancel record. In addition to states ensuring that the ICN-ORIG and ICN-ADJ are correctly populated, states using the original ICN approach should ensure that the ADJUDICATION-DATE is populated accurately. The record in the claim family with the most recent ADJUDICATION-DATE will be identified as the most recent submission of the claim^[3]. For additional information on using the original ICN approach or daisy chain ICN approach to linking claim families, please refer to T-MSIS Data Dictionary Appendix P.01.

Table 1 – Record Key Data Elements

Table 2 – Using record keys to link void claims to prior submissions - Original ICN Method

Table 3 – Using record keys to link void claims to prior submissions - Daisy Chain ICN Method

“X-12 transaction” data elements are populated with information on how the void/reversal/cancel record was processed. These data elements are identified in table 4 below. If the X-12 transaction values are not applicable to the void/reversal/cancel claim or encounter, then the data element should be reported with a null value. For example, if a void only has one Remittance Advice Remark Code (RARC), then the CLAIM-PYMT-REM-CODE-2 through CLAIM-PYMT-REM-CODE-4 would be populated with a null value.

Table 4 – X-12 Transaction Data Elements

“Adjudicated quantity” data elements are populated with values that are derived through the adjudication of the FFS claim or encounter. All “adjudicated quantity” data elements should be populated with a value of “0” on a void record. The specific data elements that should be reported with a value of “0” on void/reversal/cancel records are identified in Table 5. These are values that would include the allowed amounts, the payment amounts, and the quantities of service allowed. These data elements should be populated with “0” because the void/reversal/cancel in T-MSIS is supposed to represent the final net liability for the services on the FFS claim or encounter. The adjudicated dollar amounts and quantities on the FFS claim or encounter should not reflect the marginal change in dollar amounts or quantities before and after the void/reversal/cancel occurred. Reporting positive or negative values in these fields raises question regarding how the void/reversal/cancel records should be interpreted and whether the ADJUSTMENT-IND value is accurate.

Table 5 - Adjudicated Quantity Data Elements

All other data elements should be populated with the values from the most recent parent record that is being voided/reversed/cancelled. An example of this is presented in Table 2 in rows 2 and 3. The TOT-BILLED-AMT reported on the void record in row 3 is the same value that is reported in the TOT-BILLED-AMT reported on the adjustment record in row 2.

Additional technical instruction documents are listed below that are related to submissions of void records. This is not a list of all claims related technical instructions, but rather those that would help further understand the technical instructions above.

This document outlines the specifications for reporting diagnosis and procedure codes in T-MSIS claims files. The specifications in the technical instructions provide an explanation on how the data elements should be populated to ensure that diagnoses and procedures covered by Medicaid are accurately reported in the state’s T-MSIS file submission.

Fee-for-service and encounter claims should include pertinent diagnostic and procedure information appropriate for the claim file and relevant services. This information is important for CMS to identify, measure and evaluate Medicaid participants’ health and associated health care services delivery. Diagnosis codes are used in conjunction with procedure information from claims to support the medical necessity determination for the service rendered and, sometimes, to determine appropriate reimbursement. This information is critical and is associated with the T-MSIS priority item (TPI) Completeness of Key Claims Service Data Elements – TPI-20.

CMS expects to find diagnosis codes and procedure codes populated for most claims and encounter records in inpatient (IP), long-term care (LT) and other (OT) files. However, not all claims and encounters require, or should be populated with diagnosis and procedure codes. This can lead to confusion in how states should submit data to T-MSIS. This technical instruction document is intended to address that confusion.

Excluding denied claims, void claims, and types of claims typically used to report financial transactions (supplemental payments, capitation payments, and service tracking payments), all IP and LT claims should contain an ADMITTING-DIAGNOSIS-CODE (provided at the time of admission by the physician), as well as a primary, or principal, diagnosis code reported in DIAGNOSIS-CODE-1. States should report all diagnoses relevant for the claim to CMS - up to twelve on an IP claim and up to five on an LT claim. The primary diagnosis should always be populated in DIAGNOSIS-CODE-1, with subsequent diagnoses being coded in fields DIAGNOSIS-CODE-2 through 12 for IP claims and in field DIAGNOSIS-CODE-2 through 5 for LT claims. Diagnoses are to be coded using valid international classification of diseases (ICD)-9/10 CM codes. States should report the diagnosis in T-MSIS as coded and identified by the medical service provider and should be full valid ICD 9/10 CM codes without a decimal point. For example, 210.5 should be coded as “2105” with no decimal point. The respective diagnosis code flag should be appropriately populated to indicate if the ICD-9 or ICD-10 code set is being used.

When diagnosis codes are included on OT claims, diagnosis codes should be reported in T-MSIS as coded and identified by the medical service provider and should be full valid ICD 9/10 CM codes without a decimal point. Several types of services on OT claims, such as transportation services, DME, and lab work, are not expected to have diagnosis codes. However, OT claim records for medical services, such as outpatient hospital services, physicians’ services, or clinic services are generally expected to have at least one diagnosis code. States can submit up to 2 diagnosis codes per claim on the OT file. DIAGNOSIS-CODE-1 and DIAGNOSIS-CODE-FLAG-1 should be populated prior to populating DIAGNOSIS-CODE-2 and DIAGNOSIS-CODE-FLAG-2.

Across the three claims files states should not duplicate diagnoses within a claim for reporting purposes. Any unused diagnosis code or flag field should be left blank. If the diagnosis code is blank, the corresponding diagnosis code flag should also be blank. If the diagnosis code is not blank, the corresponding diagnosis code flag should be populated with a valid value.

IP claims are expected to have procedure codes reported in T-MSIS as coded and identified by the medical service provider when procedures are performed during an inpatient stay. The principal procedure should be reported in T-MSIS using the PROCEDURE-CODE-1 field with secondary and other procedures reported in fields PROCEDURE-CODE-2 through 6. The fields PROCEDURE-CODE-FLAG-1 through PROCEDURE-CODE-FLAG-6 are used to indicate the type of procedure code reported by the provider and should be coded either “02” (ICD-9 CM) or “07” (ICD-10 CM PCS)^[1].

On the OT file, financial transactions, denied and voided claims, and atypical services such as taxi services, home and vehicle modifications and respite services are not expected to have procedure codes. Procedure codes on professional and institutional claims in the OT file are expected to be current procedural terminology (CPT) or healthcare common procedure coding system (HCPCS) codes and should be maintained in the PROCEDURE-CODE field. PROCEDURE-CODE-FLAG on the OT file should be coded “01” (CPT 4) or “06” (HCPCS) to indicate the code set used. Dental claims will have Dental Procedures and Nomenclature codes, generally referred to as CDT codes, instead of CPT codes.  These codes should also be maintained in the PROCEDURE-CODE field and should be given a PROCEDURE-CODE-FLAG of "06” (HCPCS). Any modifiers used to improve coding accuracy should be reported in fields PROCEDURE-CODE-MOD-1 through PROCEDURE-CODE-MOD-4.

While the V2.4.0 and previous Data Dictionaries directed that procedure codes on outpatient facility claims in the OT file are expected to be reported in the HCPCS-RATE field, effective January 1, 2021 states that had been populating the OT HCPCS-RATE should have ceased doing so. As of June 24, 2022, with the release of the V3.0.0 of the Data Dictionary, this data element has been deprecated.  CMS has confirmed that nearly all states had already been reporting the procedure code on outpatient facility claims in the OT file in the PROCEDURE-CODE field before they were officially directed to cease using HCPCS-RATE.

State-specific procedure codes (PROCEDURE-CODE-FLAG coded “10” through “87”) can be used to report atypical services billed through Medicaid. The list of valid values for state-specific procedure codes must be provided to CMS.

This technical instruction document specifies the state's reporting of the professional dispensing fee to T-MSIS. This document outlines the challenges to reporting the professional dispensing fee and provides recommendations for reporting it to the Pharmacy Claim files using the data element DISPENSE-FEE (CRX141). 

According to State health official letter #16-001^[1], the professional dispensing fee should "reflect the pharmacists' professional services and costs to dispense a drug to a Medicaid beneficiary". The T-MSIS data dictionary defines dispensing fee as the "charge to cover the cost of dispensing the prescription". The professional dispensing fee applies to all drugs except for those reimbursed based on a pharmacy’s usual and customary charges. Each state has their own methodology to calculate the professional dispensing fee. Professional dispensing fee methodologies are defined by Medicaid state plan amendments. States can use various types of tiers to calculate the professional dispensing fees, such as using different fees for generic versus brand name drugs, or for drugs dispensed in urban or rural counties. States may use a separate methodology to calculate professional dispensing fees for 340B drugs^[2]and some specialty drugs.

Current professional dispensing fee rates can be accessed at medicaid.gov^[3]. The professional dispensing fee plus the ingredient costs represent the two main charges paid by Medicaid on an NCPDP transactions.

In the T-MSIS Data Dictionary V2.4.0 and prior data dictionaries, there were several challenges to reporting the professional dispensing fee to T-MSIS. When pharmacy claims are billed to Medicaid from point of sale systems on the NCPDP form, the ingredient cost submitted (NCPDP field 409-D9), the dispensing fee submitted (412-DC), incentive amount submitted (438-E3), other amount claimed submitted (480-H9), flat sales tax amount submitted (481-HA), and percentage sales tax amount submitted (482-GE) minus the patient pay amount submitted (433-DX) and other paid amount submitted (431-DV) should sum to the gross amount due (430-DU)^[4]. The NCPDP also contains fields for the dispensing fee paid (507-F7), ingredient cost paid (506-F6), and total amount paid (509-F9). Many of these fields did not clearly map to any T-MSIS data element, or appeared to map to multiple data elements. It was not clear whether the professional dispensing fee field in T-MSIS reflected the dispensing fee paid field from the NCPDP, or the dispensing fee submitted field. The resulting confusion had implications on T-MSIS header and line billed amounts and paid amounts.  Whether the value reflected a billed amount or paid amount also impacted whether the state pulled the value from the submitted claim form or the response form. An ongoing challenge is that, when pharmacy benefits are provided through managed care, encounters are submitted by pharmacy benefit managers instead of the state.

In addition to challenges mapping the professional dispensing fee to T-MSIS, some providers will not report this value on the claim forms. Providers billing usual and customary charges do not incorporate professional dispensing fees into the amounts charged for a prescription or drug. Usual and customary charges represent the actual cost paid by consumers at the point of sale, and can be set by individual providers. Providers’ usual and customary charges may not include or reflect the full amounts allowed for ingredient costs. In this case, the provider’s claim will not include the professional dispensing fee.

The following provides a crosswalk between the fields used in the NCPDP prescription and service pricing formula^[4]and corresponding T-MSIS data elements.

Table 1. Crosswalk of Prescription and Service Pricing Data Elements

In the Data Dictionary V2.4.0 and prior data dictionaries,, DISPENSE-FEE reflected the amount billed by the provider towards the professional dispensing fee. If the provider did not break out the professional dispensing fee on the NCPDP transaction, this field should have been blank in T-MSIS. There was previously no specific field in T-MSIS to capture either the professional dispensing fee amount paid, or the amount billed or paid towards ingredient costs. As of the Data Dictionary V3.0.0, data elements were added and renamed to capture and clarify professional dispensing fee amount paid, amount billed, and paid towards ingredient costs (See Table 1).

There are two fields on the NCPDP form that capture pharmacy dispenser information: Service provider ID (NCPDP 201-B1) and Provider ID (NCPDP 444-E9). Provider ID (NCPDP 444-E9) is not required on most pharmacy claims. While we do not expect this field to be frequently populated, where this is populated it should be mapped to T-MSIS. Service provider ID (NCPDP 201-B1) is required on most pharmacy claims and we expect it to be mapped to T-MSIS. A crosswalk of provider types from pharmacy claims forms to T-MSIS can be found in the Data Dictionary Appendix P.07 Table F.

This reporting reminder describes how to report DISCHARGE-DATE (CIP096 and CLT046) in the T-MSIS Claim IP and Claim LT file.

• DISCHARGE-DATE (CIP096 and CLT046)
• ADMISSION-DATE (CIP094 and CLT044)
• DATE-OF-BIRTH (ELG024)
• DATE-OF-DEATH (ELG025)
• ADJUDICATION-DATE (CIP098 and CLT050)
• PATIENT-STATUS (CIP199 and CLT141)
• BEGINNING-DATE-OF-SERVICE (CIP290)^[1]
• ENDING-DATE-OF-SERVICE (CIP291)^[1]

• States are required to report the date on which the recipient was discharged from a hospital in CCYYMMDD format.
• The date must occur on or after the admission date (ADMISSION-DATE (CIP094 and CLT044)), BEGINNING-DATE-OF-SERVICE (CIP290), and date of birth (DATE-OF-BIRTH (ELG024)) in the Eligible file.
• The date must occur on or before the adjudication date (ADJUDICATION-DATE (CIP098 and CLT050)), ENDING-DATE-OF-SERVICE (CIP291), and date of death (DATE-OF-DEATH (ELG025)) in the Eligible file.
• This is required field even when the patient dies, unless the patient is still a patient. If the patient is still admitted as a patient, the patient status code should indicate such (PATIENT-STATUS (CIP199 and CLT141).

This reporting reminder describes how to report required claims date fields in the T-MSIS files.

• Claim IP
  • ADMISSION-DATE (CIP094) (CLAIM-HEADER-RECORD-IP-CIP00002)
  • DISCHARGE-DATE (CIP096) (CLAIM-HEADER-RECORD-IP-CIP00002)
  • BEGINNING-DATE-OF-SERVICE (CIP290) (CLAIM-HEADER-RECORD-IP-CIP00002)^[1]
  • ENDING-DATE-OF-SERVICE (CIP291) (CLAIM-HEADER-RECORD-IP-CIP00002)^[1]
  • BEGINNING-DATE-OF-SERVICE (CIP243) (CLAIM-LINE-RECORD-IP-CIP00003)
  • ENDING-DATE-OF-SERVICE (CIP244) (CLAIM-LINE-RECORD-IP-CIP00003)
• Claim LT
  • BEGINNING-DATE-OF-SERVICE (CLT048) (CLAIM-HEADER-RECORD-LT-CLT00002)
  • ENDING-DATE-OF-SERVICE (CLT049) (CLAIM-HEADER-RECORD-LT-CLT00002)
  • BEGINNING-DATE-OF-SERVICE (CLT196) (CLAIM-LINE-RECORD-LT-CLT00003)
  • ENDING-DATE-OF-SERVICE (CLT197) (CLAIM-LINE-RECORD-LT-CLT00003)
• Claim OT
  • BEGINNING-DATE-OF-SERVICE (COT033) (CLAIM-HEADER-RECORD-OT-COT00002)
  • ENDING-DATE-OF-SERVICE (COT034) (CLAIM-HEADER-RECORD-OT-COT00002)
  • BEGINNING-DATE-OF-SERVICE (COT166) (CLAIM-LINE-RECORD-OT-COT00003)
  • ENDING-DATE-OF-SERVICE (COT167) (CLAIM-LINE-RECORD-OT-COT00003)
• Claim RX
  • PRESCRIPTION-FILL-DATE (CRX085) (CLAIM-HEADER-RECORD-RX-CRX00002)

• The list of impacted date data elements are always required to be reported, unless otherwise specified below.
• Discharge Date (IP – header):
  • As specified in the reporting reminder on DISCHARGE-DATE from the June 8, 2018 MACBIS CMS Coding Information listserv, this data element must be reported in CCYYMMDD format, even if it must be reformatted from the state’s source system.
  • This date should be on or after DATE-OF-BIRTH in the T-MSIS Eligible file and on or before the DATE-OF-DEATH (when applicable) in the T-MSIS Eligible file, on or before the ADJUDICATION-DATE and on or after the ADMISSION-DATE.
  • Discharge date on interim claims for long stays can be conditionally missing.
  • DISCHARGE-DATE is expected to be available even when the patient dies, and can be conditionally missing if the patient is still a patient. If the patient is still admitted as a patient, the patient status code should indicate as such (PATIENT-STATUS).
• Service Begin and End Dates (IP – header and line, LT – header and line, OT – header and line (End Date only)):
  • States should use the following guidelines when mapping service beginning and end dates from their state’s source systems. The beginning and end dates of service for the IP claim line, LT claim header, and some OT claim header and claim line segments can come from a date range qualified by RD8 of an 837i claim.
    • For claims with a ‘RD8’ date qualifier, states should populate the beginning date of service in T-MSIS with the first date from that range and the ending date of service in T-MSIS with the second date in that range.
    • For claims with a ‘D8’ date qualifier, states should use a conditional rule to populate both the T-MSIS beginning and ending date of service with the one date qualified by ‘D8’ in the 837i if no range is available.
    • The same is true when only an ‘R8’ date on a 837p, 837d, and 820 (coverage period) is mapped to the T-MSIS OT file beginning and ending date of service.
  • When the beginning and ending date of service are missing, automated validation rules could be triggered and states may need to modify their mappings or programs and possibly submit replacement files to resolve the problem.

This technical instruction document specifies requirements for reporting a beneficiary’s race in the RACE-INFORMATION-ELG00016 segment and ethnicity in the ETHNICITY-INFORMATION-ELG00015 segment both in the T-MSIS Eligible file. This document outlines the challenges of the differing standards for reporting race and ethnicity in T-MSIS. T-MSIS race and ethnicity values align with the 2011 Department of Health and Human Services (HHS) data standards, which are more granular than the OMB standard values used on most states’ Medicaid applications. This document provides instruction for states to report the RACE (ELG213) and ETHNICITY-CODE (ELG204) data elements in T-MSIS to reconcile these differing standards, as well as information on how to report race information for beneficiaries that are multiracial.

Race and ethnicity are two important beneficiary demographic data elements reported on the T-MSIS Eligible file and of interest to end users of T-MSIS data for analytic purposes. The Patient Protection and Affordable Care Act requires federal data collection efforts for health care to follow the 1997 OMB standards, although states can opt for more granular reporting as long as the categories reported  can be rolled up to the OMB standards.^[1]The T-MSIS race and ethnicity data elements currently align with the 2011 HHS Data Collection Standards for Race, Ethnicity, Sex, Primary Language and Disability Status (HHS Data Standards) published by the Office of the Assistant Secretary for Planning and Evaluation in October 2011. However, most states’ Medicaid applications collect race and ethnicity data at OMB standards, which is less granular.^[2][3][4]As the HHS data standards for race and ethnicity roll up to the OMB standards, the categories of race for “Asian Indian”, “Chinese”, “Filipino”, “Japanese”, “Korean”, “Vietnamese”, and “Other Asian” roll up to the OMB standard for race value of “Asian” , and the HHS data standards for the categories of ethnicity for “Mexican, Mexican American, Chicano/a”, “Puerto Rican”, “Cuban”, and “Another Hispanic, Latino, or Spanish origin” roll up to the OMB standard ethnicity value of “Hispanic or Latino/a”..

There is no single T-MSIS RACE (ELG213) valid value that captures a “multiracial” value for those beneficiaries that identify as multiracial. This is consistent with OMB guidance that reporting more than one race should take the form of multiple responses to a single question and not a single ‘‘multiracial’’ category.^[5] Some states have had questions regarding how to report valid values when beneficiaries self-identify in two or more race categories. Additionally, some states’ applications/systems only allow beneficiaries to report a “multiracial” category and are unsure how to translate “multiracial” to T-MSIS. See examples on how states can report multiple race values in the T-MSIS Eligible file by reporting multiple RACE-INFORMATION-ELG00016 segments in the Technical Instructions section below.

Race information is included in the calculation of a measure component for T-MSIS Priority Item (TPI) 32 – Beneficiary Demographics: Level 2.

• Eligible beneficiaries with AMERICAN-INDIAN-ALASKA-NATIVE-INDICATOR (ELG215) (formerly known as AMERICAN-INDIAN-ALASKAN-INDICATOR)  = 1 but do not have RACE = 003 (American Indian or Alaska Native).

Race and ethnicity data are also assessed through other T-MSIS state data quality measures. Some examples of these measures are below. States should refer to the Data Quality Tool (DQT) for a full listing of current data quality measures. 

• % of eligibles with unspecified, unknown, missing or invalid ethnicity
• % of eligibles with unspecified, unknown, missing or invalid race
• Ratio of errors for overlapping segment eff/end dates [RULE-2438] to all active RACE-INFORMATION (ELG00016) segments across all reporting and coverage periods
• Ratio of errors for overlapping segment eff/end dates [RULE-2413] to all active ETHNICITY-INFORMATION (ELG00015) segments across all reporting and coverage periods

For the RACE (ELG213) and ETHNICITY-CODE (ELG204) data elements, there are several valid values that refer to 
“Other”, “Unknown”, or “Unspecified” race and ethnicity categories. Please refer to Table 1 below, which describes the scenarios where these race and ethnicity categories should be reported in T-MSIS.

Table 1: Use of “Other”, “Unknown”, and “Unspecified” Race and Ethnicity Values in T-MSIS

There are several T-MSIS Race (ELG213) values that share a one-to-one mapping with the OMB standard values used on many states’ Medicaid applications and in their eligibility and enrollment systems, but there are other values that have a many-to-one mapping. This section contains instructions for situations where a state’s race and ethnicity values are less granular than the T-MSIS values and for situations where a state’s race and ethnicity values are more granular than the T-MSIS values.

Tables 2 and 3 shows an example scenario where the state uses race or ethnicity valid values equivalent to the OMB standard values and are less granular than the T-MSIS race and ethnicity valid values. Refer to the instructions following Table 3 for instruction on how to report race and ethnicity information in these situations.

Table 2: Scenario: State’s Race Valid Values are Less Granular than T-MSIS

Table 3: Scenario: State’s Ethnicity Valid Values are Less Granular than T-MSIS

• States should use the T-MSIS RACE (ELG213) valid value of “011” (Asian Unknown) when detailed Asian race codes (“004” through “009”) (E.g., Asian Indian, Chinese, Filipino, etc.) are not available. States should not use “010” (Other Asian) or “017” (Unspecified) in this instance.
• States should use the T-MSIS RACE (ELG213) valid value of “016” (Native Hawaiian or Other Pacific Islander Unknown) when detailed Native Hawaiian and Other Pacific Islander race codes (“012” through “014”) (e.g., Guamanian or Chamorro, Samoan, etc.) are not available. States should not use “015” (Other Pacific Islander) or “017” (Unspecified) in this instance.
• State should use the T-MSIS RACE (ELG213) valid value of “018” (Other) when they have a corresponding generic category to capture all other races. States should not use “017” (Unspecified) in this instance.
• RACE-OTHER (ELG214) is null. RACE-OTHER (ELG214) is only populated when RACE (ELG213) is “010” (Other Asian) or “015” (Other Pacific Islander). It would not be expected for RACE (ELG213) to be populated with “010” (Other Asian) or “015” (Other Pacific Islander) when the state’s race values are less granular than T-MSIS.
• States should use the T-MSIS ETHNICITY-CODE (ELG204) valid value of “5” (Hispanic or Latino/a Unknown) when detailed Hispanic or Latino/a ethnicity codes (“1” through “3”) (e.g., Puerto Rican, Cuban, etc.) are not available. State should not use “6” (Ethnicity Unspecified) in this instance.
• State should use the T-MSIS ETHNICITY-CODE (ELG204) valid value of “6” (Ethnicity Unspecified) when the ethnicity is unknown because the beneficiary did not provide their ethnicity or there was not opportunity offered to the beneficiary to provide it.
• ETHNICITY-OTHER (ELG271) is null. ETHNICITY-OTHER (ELG271) is only populated when ETHNICITY-CODE (ELG204) is “4” (Another Hispanic, Latino/a, or Spanish origin). It would not be expected for ETHNICITY-CODE (ELG204) to be populated with “4” (Another Hispanic, Latino/a, or Spanish origin) when the state’s ethnicity values are less granular than T-MSIS.

Tables 4 and 5 show a scenario where the state’s race or ethnicity valid values are more granular than the T-MSIS race and ethnicity valid values. The more granular values provided in tables 4 and 5 are meant to be examples, not an exhaustive list of the potential options that could be reported. Refer to the instructions following Table 4 for instruction on how to report race and ethnicity information in these situations.

Table 4: Scenario: State’s Race Valid Values are More Granular than T-MSIS

Table 5: Scenario: State’s Ethnicity Valid Values are More Granular than T-MSIS

• States should use the T-MSIS RACE (ELG213) valid value of “010” (Other Asian) when the state captures more detailed Asian race values than is available to report in T-MSIS (e.g., Cambodian, Indonesian, Laotian, Malaysian, Thai). States should also use the data element RACE-OTHER (ELG214) to report the more specific Asian race in this free-text field.
• States should use the T-MSIS RACE (ELG213) valid value of “015” (Other Pacific Islander) when the state captures more detailed Pacific Islander race values than is available to report in T-MSIS (e.g., Fijian, Tongan, Marshallese). States should also use the data element RACE-OTHER (ELG214) to report the more specific Pacific Islander race in this free-text field.
• State should use the T-MSIS RACE (ELG213) valid value of “018” (Other) when the state captures more detailed race values than is available to report in T-MSIS that are not Other Asian or Other Pacific Islander (e.g., Aboriginal Australian, Sami, Berber). States should also use the data element RACE-OTHER (ELG214) to report the more specific other race in this free-text field.
• States should use the T-MSIS ETHNICITY-CODE (ELG204) valid value of “4” (Another Hispanic, Latino/a, or Spanish origin) when the state captures more detailed Hispanic or Latino/a ethnicity codes than is available to report in T-MSIS. States should also use the data element ETHNICITY-OTHER (ELG271) to report the more specific ethnicity value in this free-text field.

States can report beneficiaries with multiple simultaneously active values for RACE (ELG213), as the data element is a primary key for the RACE-INFORMATION-ELG00016 segment. The T-MSIS technical requirements expect that the RACE (ELG213) and RACE-OTHER (ELG214) values are different on each simultaneously active segment for a given beneficiary.

States can also report beneficiaries with multiple simultaneously active values for ETHNICITY-CODE (ELG204), as the data element is a primary key for the ETHNICITY-INFORMATION-ELG00015 segment. The T-MSIS technical requirements expect that the ETHNICITY-CODE (ELG204) values are different on each simultaneously active segment for a given beneficiary.

States should use the instructions above to determine the appropriate T-MSIS race and ethnicity valid values to report, depending on whether their state race valid values are more or less granular than the T-MSIS values, and if multiple values apply to a given beneficiary, the state can report all of the applicable values. Three examples of situations where individuals self-identify multiple racial categories or self-identify multiple ethnic categories and how to report them in T-MSIS follows:

• Example 1: The state captures an individual’s self-identified racial categories as: Black or African American, Korean, and Thai. The state values are more granular than the T-MSIS RACE (ELG213) values. In T-MSIS, we would expect the following RACE-INFORMATION-ELG00016 segments for this individual.

Table 6: Example 1: Individual Reporting Multiple Racial Categories in T-MSIS – State’s Race values are more granular than T-MSIS

• Example 2: The state captures an individual’s self-identified racial categories as: White and Asian. The state values are less granular than the T-MSIS RACE (ELG213) values. In T-MSIS, we would expect the following RACE-INFORMATION-ELG00016 segments for this individual. 

Table 7: Example 2: Individual Reporting Multiple Racial Categories in T-MSIS – State’s Race values are less granular than T-MSIS

• Example 3: The state captures an individual’s self-identified ethnicity as: Mexican, Mexican American, Chicano/a; Puerto Rican; and Honduran. The state values are more granular than the T-MSIS ETHNICITY-CODE (ELG204) values. In T-MSIS, we would expect the following ETHNICITY-INFORMATION-ELG00015 segments for this individual.

Table 8: Example 3: Individual Reporting Multiple Ethnic Categories in T-MSIS – State’s Ethnicity values are more granular than T-MSIS

If state systems/applications were not previously allowing beneficiaries to report multiple race values and it is therefore necessary to update their systems/applications to capture multiple RACE values, only beneficiaries enrolled (or re-enrolled) after application updates were put in place are expected to be reported with multiple race values (when applicable because the beneficiary has reported multiple races).  Historical data for prior/current beneficiaries – those enrolled before the application update – will not include multiple races at the beneficiary level because it would not have been possible for the beneficiary to have declared multiple races at the time. If a beneficiary enrolls or re-enrolls after the application update and reports multiple race values, the RACE-DECLARATION-EFF-DATE on the beneficiary’s RACE-INFORMATION-ELIGIBLE-ELG00016 segments capturing the race values should reflect the date of enrollment using the updated application. Race and ethnicity data from the state’s Medicaid application or any data system that uses federal match to support it is expected to comply with ACA and OMB standards (ACA Sec. 4302; e.g., minimum code set, multiple choice, self-reported) and must be provided to T-MSIS. While states cannot require that a beneficiary provide race and/or ethnicity information on their Medicaid/CHIP application, they should at least encourage it. If the state can also report to T-MSIS race or ethnicity data from any other state application or system not supported by federal match (and therefore not necessarily held to the same ACA and OMB standards), reporting of this data is considered a useful and necessary supplement to the data available from the state’s Medicaid application.

On February 26, 2016, CMCS issued a State Health Official (SHO) letter, SHO #16-002, to inform state Medicaid agencies and other state health officials about an update in payment policy affecting federal funding for services received by Medicaid-eligible individuals, who are American Indians and Alaska Natives (AI/AN) through facilities of the Indian Health Service (IHS), whether operated by IHS or by Tribes. The SHO letter explained the requirements necessary to allow amounts paid by the State to be eligible for the enhanced federal matching authorized under section 1905(b) of the Social Security Act at a rate of 100 percent. 

To support the evaluation of this payment policy using T-MSIS data, it is necessary to report relevant T-MSIS data elements in accordance with the SHO letter. The SHO letter (PDF, 128.37 KB), FAQs (PDF, 185.8 KB) related to the SHO letter and the T-MSIS data dictionary are located on Medicaid.gov.

Instructions contained in the current T-MSIS Data Dictionary are outdated and are scheduled for updating in the next release of the data dictionary. The CMS technical instructions below supersedes the current definitions and coding requirements and should be followed.

If a state plans to request reimbursement consistent with the SHO letter, its coding of T-MSIS files should comply with the technical instructions below.

For each AI/AN Medicaid beneficiary for whom the state plans to request reimbursement consistent with the SHO letter, the state must include in its eligibility file a RACE-INFORMATION record segment (ELG00016) with Data Element # ELG215 populated with valid value “1” (Individual meets the definition of an American Indian/Alaska Native).

Data Element # ELG215 is the AMERICAN-INDIAN-ALASKA-NATIVE-INDICATOR field.

Note that the former name for Data Element # ELG215 in the T-MSIS data dictionary is “CERTIFIED-AMERICAN-INDIAN-ALASKA-NATIVE-INDICATOR.” This data element was renamed “AMERICAN-INDIAN-ALASKA-NATIVE-INDICATOR” in the T-MSIS Data Dictionary V3.0.0.

DEFINITION OF AMERICAN INDIAN OR ALASKA NATIVE:

"American Indian or Alaska Native" means any individual defined at 25 USC 1603(13), 1603(28), or 1679(a), or who has been determined eligible as an Indian, pursuant to 42 CFR § 136.12. This means the individual:

1. Is a member of a Federally-recognized Indian tribe;
2. Resides in an urban center and meets one or more of the following four criteria:
   1. Is a member of a tribe, band, or other organized group of Indians, including those tribes, bands, or groups terminated since 1940 and those recognized now or in the future by the State in which they reside, or who is a descendant, in the first or second degree, of any such member;
   2. Is an Eskimo or Aleut or other Alaska Native;
   3. Is considered by the Secretary of the Interior to be an Indian for any purpose; or
   4. Is determined to be an Indian under regulations promulgated by the Secretary of Health and Human Services;
3. Is considered by the Secretary of the Interior to be an Indian for any purpose; or
4. Is considered by the Secretary of Health and Human Services to be an Indian for purposes of eligibility for Indian health care services, including as a California Indian, Eskimo, Aleut, or other Alaska Native.

Valid Values for the AMERICAN–INDIAN/ALASKA-NATIVE INDICATOR:

The value chosen for the T-MSIS American Indian/Alaska Native Indicator should reflect answers provided by applicants who complete Appendix B of the Marketplace/Medicaid application, which asks the following questions:

1. Are you a member of a federally recognized tribe?
2. Has this person ever gotten a service from the Indian Health Service, a tribal health program, or urban Indian health program, or through a referral from one of these programs?

Valid values for Data Element # ELG215 are:

0 = Individual does not meet the definition of an American Indian/Alaska Native.

1 = Individual meets the definition of an American Indian/Alaska Native.

In the T-MSIS Provider File, the state must include the following:

Provider File Records

1. Each IHS facility (i.e., hospitals, clinics, FQHCs and nursing facilities) and Tribal facility^[1] (i.e., Tribe-operated hospitals, clinics, FQHCs and nursing facilities) needs to have a record in the Provider File.
2. Each specialist and other non-IHS/Tribal provider^[2] needs to have a record in the Provider File.

Written Care Coordination Arrangements

1. A “written care coordination arrangement” between the IHS/Tribal hospital or clinic and each specialist or other non-IHS/Tribal provider must exist.

T-MSIS PROV-AFFILIATED-GROUPS record segments

1. For each of the written care coordination arrangement relationships, a T-MSIS PROV-AFFILIATED-GROUPS record segment (PRV00008) must be created.  To clarify, the information being collected:
   1. SUBMITTING-STATE-PROV-ID = the ID of the specialist or other non-IHS/Tribal provider
   2. SUBMITTING-STATE-PROV-ID-OF-AFFILIATED-ENTITY = the ID of the hospital, clinic, FQHC, or nursing facility with whom the provider has a written care coordination arrangement
   3. PROV-AFFILIATED-GROUP-EFF-DATE = the date that the written care coordination arrangement becomes effective
   4. PROV-AFFILIATED-GROUP-END-DATE = the date that the written care coordination arrangement ceases to be in effect (If the care coordination agreement is open-ended – i.e., no specific end date – the state should enter 99991231.)

In the T-MSIS Claims Files, the state must include the following:

Billing Provider Identifiers

1. On Claim-IP, Claim-LT, Claim-OT & Claim-RX:
   1. BILLING-PROV-NUM
   2. BILLING-PROV-NPI-NUM

Referring Provider Identifiers

1. On Claim-IP, Claim-LT, Claim-OT:
   1. REFERRING-PROV-NPI-NUM
   2. REFERRING-PROV-NUM
2. On Claim-RX:
   1. PRESCRIBING-PROV-NPI-NUM
   2. PRESCRIBING-PROV-NUM

Rendering Provider Identifiers

1. On Claim-IP, Claim-LT, Claim-OT:
   1. SERVICING-PROV-NPI-NUM
   2. SERVICING-PROV-NUM
2. On Claim-RX:
   1. DISPENSING-PRESCRIPTION-DRUG-PROV-NPI
   2. DISPENSING-PRESCRIPTION-DRUG-PROV-NUM

Referral Numbers

1. On Claim-IP, Claim-LT, Claim-OT & Claim-RX:
   1. PRE-AUTHORIZATION-NUM

Indian Health Service (IHS) Indicator

1. On Claim-IP, Claim-LT, Claim-OT & Claim-RX:
   1. IHS-SERVICE-IND
   2. (To capture Services received by Medicaid-eligible individuals who are American Indian or Alaska Native (AI/AN) through facilities of the Indian Health Service (IHS), whether operated by IHS or by Tribes, as of T-MSIS Data Dictionary V3.0.0 a new data element, IHS-SERVICE-IND, was added.)

Dates of Service

1. On Claim-IP, Claim-LT, Claim-OT:
   1. BEGINNING-DATE-OF-SERVICE
   2. ENDING-DATE-OF-SERVICE
      
      (CMS would expect the BEGINNING-DATE-OF-SERVICE to fall between PROV-AFFILIATED-GROUP-EFF-DATE and PROV-AFFILIATED-GROUP-END-DATE) and (ENDING-DATE-OF-SERVICE to fall between PROV-AFFILIATED-GROUP-EFF-DATE and PROV-AFFILIATED-GROUP-END-DATE)

Date Prescribed

1. On Claim-RX:
   1. DATE-PRESCRIBED
      
      (CMS would expect the DATE-PRESCRIBED to fall between PROV-AFFILIATED-GROUP-EFF-DATE and PROV-AFFILIATED-GROUP-END-DATE)

The T-MSIS data dictionary defines “allowed amount” as the maximum amount “determined by the payer as being 'allowable' under the provisions of the contract prior to the determination of actual payment.” In plain language, the allowed amount represents the maximum payer liability for a given service. It is what the payer would pay if there was no patient liability (e.g., no deductible or co-pay) or other liabilities preceding the payer in the coordination of benefits hierarchy.  The allowed amount can be based on the billing provider’s usual, customary and reasonable billing amount, or it can be based on the negotiated rate that the payer and provider have agreed to.

The allowed amount should not be confused with the Medicaid paid amount. The Medicaid paid amount represents the Medicaid/CHIP liability (or, for encounter records, a managed care plan’s liability) of the allowed amount. The allowed amount, on the other hand, encompasses all payments determined by Medicaid (e.g., Medicaid paid amount, co-insurance, deductibles, co-pays, etc.). Allowed amounts should be reported for all services reimbursed on a fee for service basis (including claims paid as fee for service by managed care organizations) as well as any bundled payments or alternative payment models that use allowed amounts as part of payer liability determination.

When evaluating overall spending for medical services, allowed amounts are more useful than paid amounts because they combine all payments determined by the payer and therefore provide a more accurate representation of the overall cost of a given service. Additionally, because the allowed amount captures deductibles and copays, it allows researchers to more accurately evaluate service costs across individuals with different cost-sharing arrangements. For example, the Medicaid paid amount for the same service from the same provider would be lower for individuals with high deductibles than it would be for individuals with lower deductibles. In this situation, if a study were to use paid amounts instead of allowed amounts, researchers may make erroneous conclusions about what factors influence the cost of the service. For this reason, evaluations should use allowed amounts and not paid amounts when comparing service costs in different cost sharing scenarios (or when potential cost sharing differences are not known).

There are several challenges states face when populating allowed amounts:

• Some claims data warehouse structures make it difficult to link allowed amount values to the claim they apply to. 
• Managed care organizations (MCOs) often negotiate allowed amounts with providers during provider contracting and may limit the sharing of allowed amounts with outside organizations.  However, states are required to collect this and have the authority to do so, as clarified at 42 C.F.R. § 438.242(c)(3). 
• Contracting concerns may also make sub-contractors hesitant to share allowed amounts in sub-capitated arrangements. 
• Allowed amounts may not be available when payments are not determined on a per-service basis, such as for bundled services or for services paid using an alternative payment models. 
• Some states may not have established standardized procedures for passing allowed amounts from the MCO to the state. In such a situation, MCOs may not know how to provide allowed amounts, and if MCOs do share allowed amounts, states may not know where to find them.

Allowed amounts are included in the calculation of two T-MSIS Priority Item (TPI) 16 measure components. 

• TPI 16: Completeness and Consistency of Claim Payment Data Elements
  • % of claims that have total Medicaid paid amount greater than a non-zero total allowed amount^[1]
  • % of claim lines with PAYMENT-LEVEL-IND=2 (claim detail) and Medicaid paid amount greater than the allowed amount^[2]

• FFS claims paid by the state: Allowed amounts are a necessary part of the payment determination process for FFS claims so they should be available for all claims paid by the state. Though allowed amounts may be difficult to identify in some data warehouse structures, it should be possible to link services to the appropriate allowed amount. If the state T-MSIS team is not able to identify the appropriate values for allowed amount reporting, they should reach out to others within the state who are familiar with how claim payments are calculated or how payments are maintained in the state data warehouse.
• MCO Encounters: Obtaining allowed amount information for encounters is more complicated than it is for claims paid by the state. Allowed amounts are negotiated by the MCO as part of provider contracting and are often considered trade secrets. Releasing a large quantity of allowed amount information may put an MCO at a competitive disadvantage in their marketplace and it may damage their position in subsequent provider negotiations. Subcontractors may be unwilling to share allowed amounts in sub-capitated arrangements for this same reason. However, 42 C.F.R. § 438.242(c)(3) clarifies that states are authorized and required to collect allowed amount information from MCOs for encounter records.

States should clarify their data sharing expectations with MCOs to reduce confusion and to ensure MCOs are sharing allowed amounts appropriately and in a way that the state can use them. As specified at 42 C.F.R. § 438.242(c)(2) and (4), states must specify in an MCO’s contract the level of detail and specifications for submitting encounter data, including allowed amounts.  This could be done via a cross reference in the contract to the state’s electronic data interchange (EDI) companion guide.

Allowed amounts are recorded at the header and at the line for all claim file segments (IP, LT, OT, RX). The total allowed amount reported at the header for a given claim should equal the sum of the line level allowed amounts for that claim when claim payment is determined at the line level. Because the claim allowed amount represents payer liability prior to the determination of other liabilities, the sum of the Medicaid paid amount, the beneficiary coinsurance amount, the beneficiary copayment amount, and the beneficiary deductible amount should not exceed the total allowed amount on a given claim.

Table 1: Data elements for recording allowed amounts

The ALLOWED-CHARGE-SRC data element is included in the inpatient claim header file segment (CIP00002) and was originally intended to collect information relevant to the allowed amount determination process. However, this data element is scheduled to be retired and states will no longer be required to provide information for this data element going forward.  This change will be reflected in future versions of the T-MSIS data dictionary.

This document outlines the specifications for reporting the amount the Medicaid agency or managed care plan pays towards a beneficiary’s Medicare coinsurance and deductible amount in the T-MSIS claims files. The specifications in the technical instructions provide a detailed explanation on how the data elements should be populated to ensure Medicare coinsurance and deductible amounts are identifiable in states’ T-MSIS file submission.

Medicaid beneficiaries who also qualify for Medicare coverage are known as “dual” eligible or just “duals”. Claims for duals are typically first billed to Medicare and then to Medicaid. Medicare calculates and deducts contractually allowable charge, deductible, and/or coinsurance and pays the remainder. Then when the claim is subsequently sent to Medicaid, as the payer of last resort, Medicaid then typically determines its own contractually allowable charge amount, deducts the Medicare payment, and determines how much of the remaining allowable charges Medicaid is contractually obligated to pay the provider on behalf of the beneficiary for their deductible and/or coinsurance and how much of the deductible and/or coinsurance the provider is contractually obligated to write-off. Note that from Medicare’s perspective, the entire annual deductible amount must be incurred before coinsurance becomes applicable or Medicare makes a payment. Typically once a deductible has been incurred in full for a given type of benefit no more deductible is applied for the rest of the calendar year for that type of benefit, only Medicare payments or coinsurance. Claims billed to the Medicaid program for the beneficiary’s Medicare deductible and/or coinsurance are referred to as crossover claims.

States face two primary challenges when reporting to T-MSIS the amount the Medicaid agency paid towards the Medicare coinsurance and deductible payment.  The first challenge is that some states report to T-MSIS the entire amounts that Medicare applied to coinsurance and/or deductible instead of the amounts that the Medicaid agency actually paid towards them after calculating the Medicaid contractual obligation, which are frequently different values. States also face challenges reporting payment information on crossover claims when the payments towards either the coinsurance and/or deductible are not explicitly tracked in the state’s system as anything more specific than the state’s obligation to pay the provider anything. 

The Medicare coinsurance and Medicare deductible amounts can be reported in T-MSIS under four data elements: MEDICARE-COINS-AMT, MEDICARE-DEDUCTIBLE-AMOUNT, TOT-MEDICARE-COINS-AMT, and TOT-MEDICARE-DEDUCTIBLE-AMOUNT (See Table 1 below for specific data element numbers). The fields should capture the amount paid by Medicaid to the provider not the amount Medicare applied to coinsurance and/or deductible. Therefore, the sum of the amount paid towards the coinsurance and deductible amount is expected to be equal to the Medicaid paid amount in T-MSIS.   

For each claim header, states should report the amount paid by the Medicaid agency toward the claim’s total Medicare coinsurance and deductible using the data elements TOT-MEDICARE-COINS-AMT and TOT-MEDICARE-DEDUCTIBLE-AMT, respectively.  If the state is unable to separate the coinsurance payment from the deductible payment, the MEDICARE-COMB-DED-IND field should be reported with the valid value of ‘1’.  In addition, the TOT-MEDICARE-COINS-AMT field should be spaced-filled or missing and the combined coinsurance and deductible payment amount should be reported in the TOT-MEDICARE-DEDUCTIBLE-AMT. If payment for a crossover claim is determined at the claim header level (PAYMENT-LEVEL-IND=1), MEDICAID-PAID-AMT at the line level does not need to be populated, but TOT-MEDICAID-PAID-AMT at the claim header level should be populated with the total amount paid on the crossover claim.

On the RX file, Medicare coinsurance and deductible amounts can be reported at the line level^[1].  If crossover payments for coinsurance and deductible are adjudicated at the line level (PAYMENT-LEVEL-IND=2), states should report the amount paid by the Medicaid agency toward the claim line’s Medicare coinsurance and/or deductible using the data elements MEDICARE-COINS-AMT and/or MEDICARE-DEDUCTIBLE-AMT, respectively. If the state is unable to separate the coinsurance payment from the deductible payment, the MEDICARE-COMB-DED-IND field should be reported with the valid value of ‘1’.  In addition, the MEDICARE-COINS-AMT field should be spaced-filled or missing and the combined coinsurance and deductible payment amount should be reported in the MEDICARE-DEDUCTIBLE-AMT.  If more than one claim line is reported and claim payment is determined at the line level, then sum of the MEDICAID-PAID-AMT values reported at the claim line level should equal the TOT-MEDICAID-PAID-AMT reported at the header level.

Table 1 - Crossover Claim Data Elements

This guidance document outlines the specifications for reporting health insurance premium payments (HIPP) (AKA premium assistance subsidy payments) on the OT file. The specifications in the guidance provide a detailed explanation on how the data elements should be populated to ensure premium payments are uniquely identifiable in states’ T-MSIS file submissions.

Medicaid services have historically been provided primarily on a fee-for-service basis paid directly by the state Medicaid agency or through managed care organizations that contract with the state. Many states have expanded, or have plans to expand, assistance that allows beneficiaries to purchase health insurance on the private market. As health insurance premium payments are becoming more common, accurate representation of these payments in the T-MSIS data is critical.

Most states did not report premium assistance payments in MSIS and no specific guidance was ever released. In both MSIS and T-MSIS, a TYPE-OF-SERVICE (COT186) value “121” Premium payments for private health insurance is available to identify a record as a premium assistance payment. These payments typically would be reported with the same TYPE-OF-CLAIM (COT037) value as a capitation payment to a managed care organization (“2”, “B” or “V”).  However, reporting premium assistance payments as a capitation payment has limitations since the premium assistance payments could be made on behalf of more than one beneficiary. For example, a policy could cover a parent and two children, so a single premium assistance payment would cover three beneficiaries, not all of whom are necessarily eligible for Medicaid.

A payment that cannot be attributed to a single beneficiary is called a Service Tracking Payment in T-MSIS. The documentation in Table 1 (PDF, 183.47 KB) specifies guidance for reporting premium assistance payments in the OT file. The table specifies the data element name, the data element number, the value populated in the data element, and further explanation of how the field should be populated under this circumstance. A separate claim line record segment (CLAIM-LINE-RECORD-OT-COT00003) should be reported for each beneficiary covered by the insurance policy.

The guidance in Table 1 (PDF, 183.47 KB) focuses on data elements that are specifically germane to premium assistance payments and is not exhaustive. Specifications are provided for reporting cases in which there is a single beneficiary and cases with multiple beneficiaries. Other fundamental data elements such as adjudication date, internal control numbers, and line numbers are still expected to be populated consistent with reporting service tracking payments. See T-MSIS Data Dictionary Appendix P.02 for additional information.

Premium assistance payment for a policy that only covers a single Medicaid or CHIP beneficiary should be reported in a manner more consistent with the way a managed care capitation payment is reported, with the exception of the plan ID reported on a premium assistance payment. Individuals enrolled in premium assistance are not expected to have a corresponding managed care enrollment reported in the eligibility file because it does not meet the definition of managed care in federal statutes and regulations therefore there would be no plan ID reported on the premium assistance payment, whether it be for a policy that covers one person or multiple people.

This best practice document outlines the challenges states have faced when reporting the CHIP-CODE data element in the T-MSIS Eligible file. CHIP-CODE is used to distinguish among Medicaid, Medicaid Expansion CHIP, and Separate CHIP populations when looking at enrollment and utilization data.

Created as part of the Balanced Budget Act of 1997, the Children's Health Insurance Program (CHIP) builds on Medicaid to provide insurance coverage to uninsured, low-income children in families whose income is above Medicaid income-eligibility thresholds. States may use CHIP funds to expand their Medicaid programs (Medicaid Expansion CHIP), create a program separate from their existing Medicaid programs (Separate CHIP), or adopt a combination of both approaches. Although Congress provided states with significant flexibility in program implementation and characteristics, prior to T-MSIS states were required to report complete, person-level eligibility and claims data for enrollees in Medicaid Expansion CHIP programs to the Medicaid and CHIP Statistical Information System (MSIS). States had the option to include Separate CHIP enrollees as part of their MSIS reporting, and those states that wished to do so submitted only a subset of eligibility data elements (and excluded all claims information).^[1] On August 4, 2010, the Center for Medicaid and CHIP Services (CMCS), part of the Centers for Medicare & Medicaid Services (CMS), issued a revised MSIS Data Dictionary (Release 3.1), which provided instructions to states for submitting complete, Separate CHIP eligibility and claims data effective October 1, 2010. The release encouraged states to provide complete reporting as soon as possible after this date; however, several states did not move to full Separate CHIP reporting under MSIS.

Under T-MSIS states are expected to report complete data on eligible data elements for both Medicaid Expansion CHIP and Separate CHIP enrollees. This full reporting in T-MSIS ensures that CHIP has a nationwide, person-based data set, providing much more flexibility for data analysis, such as tracking when low-income children move between these different programs as their eligibility circumstances change. These more complete data offer researchers a more sophisticated understanding of CHIP enrollment and utilization patterns and how they compare to Medicaid.

Data users rely on the T-MSIS data element CHIP-CODE to distinguish among Medicaid, Medicaid Expansion CHIP, and Separate CHIP populations when looking at enrollment and utilization data. It is imperative that states provide reliable data in this field, especially because the CHIP-CODE field is in the VARIABLE-DEMOGRAPHICS-ELIGIBILITY-ELG00003 record segment, which is separate from the individual's historical and active enrollment periods that are under the ENROLLMENT-TIME-SPAN-SEGMENT-ELG00021 record segment. To ensure that people are properly assigned to the correct codes, states must understand their own unique programs and upstream systems to assign enrollees to one of these CHIP-CODES values:

• '1' = Individual was Medicaid-eligible, but was not included in either Medicaid Expansion CHIP or a separate Title XXI CHIP for the month. These include blind and disabled people and low-income families with dependent children.
• '2' = Individual was included in Medicaid Expansion CHIP and subject to enhanced federal matching for the month. States with Medicaid-Expansion CHIP programs have built upon existing Medicaid programs to include low-income children whose family incomes are above Medicaid income eligibility thresholds.
• '3' = Individual was not Medicaid Expansion CHIP eligible, but was included in a separate Title XXI CHIP for the month. States using Separate CHIP have used CHIP funds to create separate programs outside of their Medicaid programs.

A great challenge for many states is bridging various data systems that are often administered by different departments or housed in different systems, making it more difficult to obtain and reconcile the data needed for T-MSIS reporting. This might be particularly true for states with a Separate CHIP program because it is not part of the states' regular Medicaid operations.

States whose CHIP data originate across separate data systems have to match, merge, and reconcile data from these different systems to provide nonconcurrent values reported to CHIP-CODE. States should make sure that their CHIP-CODE data are reliable and consistent with other data fields. For example, Medicaid Expansion CHIP or Separate CHIP enrollees are not expected to be reported with RESTRICTED-BENEFITS-CODE = '3', which indicates benefits restricted to Medicare cost-sharing expenses.

As a way of assessing data quality and completeness, states can compare T-MSIS CHIP counts with enrollment information reported to the CHIP Statistical Enrollment Data System (SEDS), which includes CHIP enrollment counts submitted by states to CMS on a quarterly basis and can be considered an important source for validating T-MSIS data. We generally expect the counts of Medicaid Expansion CHIP and Separate CHIP enrollees in T-MSIS to be reasonably close to the counts reported to the CHIP SEDS reporting system for CHIP.^[2]When these counts differ, it is worth exploring possible causes of the divergence. Sometimes there is a reasonable explanation (for example, some states might report unborn infants as children in CHIP SEDS, but capture them under the MSIS IDs of their pregnant mothers in T-MSIS), but other times it might lead to detection of an error in state reporting, whether on the T-MSIS or the CHIP SEDS side.

ICD-10-CM diagnosis codes related to social determinants of health (SDOH), such as housing, employment, and food insecurity, range from Z55-Z65. These codes are a subset of “Z Codes” Z00-Z99 that are used to identify “factors influencing health status and contact with health services”. Use of SDOH “Z Code” data can help improve care coordination, patient experience, and health outcomes. Like all other ICD-10-CM codes, “Z Codes”, including those related to SDOH, are reported using the various DIAGNOSIS-CODE data elements in the T-MSIS Claims files (Claim IP, Claim LT, and Claim OT).

• ADMITTING-DIAGNOSIS-CODE (CIP030, CLT027)
• DIAGNOSIS-CODE-1 (CIP032, CLT029, COT027)
• DIAGNOSIS-CODE-2 (CIP035, CLT032, COT030)
• DIAGNOSIS-CODE-3 (CIP038, CLT035)
• DIAGNOSIS-CODE-4 (CIP041, CLT038)
• DIAGNOSIS-CODE-5 (CIP044, CLT041)
• DIAGNOSIS-CODE-6 (CIP047)
• DIAGNOSIS-CODE-7 (CIP050)
• DIAGNOSIS-CODE-8 (CIP053)
• DIAGNOSIS-CODE-9 (CIP056)
• DIAGNOSIS-CODE-10 (CIP059)
• DIAGNOSIS-CODE-11 (CIP062)
• DIAGNOSIS-CODE-12 (CIP065)

The following information applies to all ICD-10-CM diagnosis codes, including “Z codes” described above. 

• States should report diagnosis codes in T-MSIS in the order that they come in on the claim. 
• States should report as many diagnosis codes as the T-MSIS architecture allows. Changes to the file layouts of the T-MSIS Claim LT and Claim OT files may be forthcoming to accommodate additional diagnoses codes in these files. 
• For assistance, please refer to the ICD-10-CM Official Guidelines for Coding and Reporting.

This guidance specifies state’s reporting requirements for an individual’s eligibility and enrollment into the Medicaid health home program as well as other relevant segments. This document outlines the challenges to reporting on the health home program in the Transformed Medicaid Statistical Information System (T-MSIS) and provides recommendations for health home reporting in the Eligible, Managed Care, Provider, and Claim-OT files.

Section 2703 of the Affordable Care Act (ACA) added Section 1945 to the Social Security Act which authorized the Medicaid state plan option to implement health homes for individuals with chronic conditions, including dual eligible beneficiaries. The ACA also provided states a 90% federal match for health home services during the first two years that an approved health home State Plan Amendment (SPA) is in effect^[1]. The health home option became available to states on January 1, 2011. Health home services include: comprehensive care management, care coordination, health promotion, comprehensive transitional care from inpatient to other settings, including appropriate follow-up, patient and family support, referral to community and social support services, if relevant and the use of health information technology (HIT), as feasible to link services. To be eligible for health home services, an individual must be a Medicaid beneficiary with: (1) two chronic conditions; (2) one chronic condition and risk for a second; or (3) a serious mental illness. States can target Medicaid beneficiaries with specific chronic conditions such as mental health conditions, substance abuse disorder, asthma, diabetes, heart disease, HIV/AIDS, and being overweight (body mass index over 25).^[2] States may also target other chronic conditions. States must designate one or more type of provider arrangements for the delivery of the health home services: designated provider, team of health care professional or health team. A state can have more than one health home SPA, serving different target groups or regions within the state but an individual can only be in one health home at a time. As of August 2019, twenty-one states and the District of Columbia have 36 approved health home programs^[3].

There are wide variances in reporting health home data elements in T-MSIS among states with health home programs which lead to inconsistent reporting across state programs. These differences lead to misinterpretations when assessing health home programs, tracking enrolled beneficiaries, and monitoring utilization of health home services and health home expenditures. Without uniform reporting, trends and patterns across programs cannot be analyzed. The following list describes the issues that CMS observed from T-MSIS state submissions by file type.

• Eligible File: There are three segments on the Eligible File that should be reported to document a beneficiary’s enrollment in a health home program. All three of these segments should be populated if a beneficiary is enrolled in a health home program. These segments respectively document (1) the beneficiary’s enrollment in a specific health home state plan amendment, (2) identifies the beneficiary’s health home provider(s), and, (3) identify the beneficiary’s chronic condition(s). In some states, only one or two of the segments have been reported for health home enrollees. Additionally, states are misreporting health home participation on the managed care participation segment
• Managed Care Plan File: States are misreporting health home entities on the Managed Care Plan File
• Provider File: : Few states are reporting on health home providers. The health home provider receiving the payment is important as it tracks the provider’s enrollment with the state as a health home provider.
• Claim OT File: The OT file is used to report health home service utilization and payments to the health home provider. Few states are reporting the health home valid values for Benefit Type and Category of Service for health home authorized services; both of which are required fields. The absence of this information could lead to a misrepresentation of the type, volume, and expenditures of health home services. Additionally, there are reporting errors for the per-member-per-month (PMPM) payments for health home services.

To address the completeness and reliability of health home-related T-MSIS data, CMS has provided the following guidance on how to report health home participation on the eligible file; how to document health home provider participation; how to report services provided by a health home and; how to report PMPM payments for health home services. In addition to the guidance provided below, states are also encouraged to review the November 2010 State Medicaid Director (SMD) letter on Health Homes and the January 2016 FAQs on health homes^[4].

States unsure of which codes apply to the Health Homes SPA(s) should refer to the boxes checked in the approved SPA pages for each health home SPA. If the state does not have the approved SPA for reference, all approved health home SPAs can be found on the Medicaid Health Homes SPA Overview (PDF, 295.82 KB). 

Health Home SPA Participation

All beneficiaries enrolled in a health home should be reported on the HEALTH-HOME-SPA-PARTICIPATION-INFORMATION-ELG00006 file segment of the Eligible File. It is important to correctly identify both the information reported in the HEALTH-HOME-SPA-NAME (ELG107) and HEALTH-HOME-ENTITY-NAME (ELG108) data elements. A state can have more than one health home SPA and a beneficiary can be eligible, and decide to enroll in, different health home entities, but can only participate in one health home program at a time.

• The HEALTH-HOME-SPA-NAME is used to report the name of the health home state plan amendment. If you are not sure of the program name, search for “Name of Health Home Program” in the approved SPA.
• The HEALTH-HOME-ENTITY-NAME field is used to document the name of the health home entity, which can be one of three types; (1) designated providers such as physicians, community health centers, community mental health centers, or group practices, (2) a team of health professionals (e.g. physician, nurse, social worker, etc.) co-located in a clinical setting, or virtually linked, or (3) a health team, including all specified providers
• Both the HEALTH-HOME-SPA-NAME and HEALTH-HOME-ENTITY-NAME data elements are used across multiple file segments. The values for the state plan amendment name and the health home entity name should be consistent across all file segments.

There are also three dates that are reported on the HEALTH-HOME-SPA-PARTICIPATION-INFORMATION-ELG00006 segment which are used to capture the period of health home enrollment.

• The HEALTH-HOME-SPA-PARTICIPATION-EFF-DATE (ELG109) and HEALTH-HOME-SPA-PARTICIPATION-END-DATE (ELG110) data elements are used to capture the period of time that the individual beneficiary participates in the health home program.
• The HEALTH-HOME-ENTITY-EFF-DATE (ELG111) data element is used to document the date the health home was approved as a health home entity under the SPA.
• A beneficiary’s health home participation is tied to the health home entity. The beneficiary should always have at least one active health home entity during the period of their health home enrollment.

If a beneficiary changes the health home entity through which they receive their care, the record with the previous health home entity should continue to be reported. A new record should be reported with the new health home entity information. The HEALTH-HOME-SPA-PARTICIPATION-EFF-DATE (ELG109) under the new health home entity should be the same as under the prior health home entity unless there was also a break in the beneficiary’s Health Home SPA participation. The beneficiary’s dates of participation with the health home entities will be captured in the HEALTH-HOME-SPA-PROVIDERS-ELG00007 segment. In the example provided in Table 1, the beneficiary with MSIS ID 123456 is reported with a health home entity changes from Community Care to Evergreen Health. A beneficiary’s original record with Community Care is reported with a HEALTH-HOME-SPA-PARTICIPATION-END-DATE (ELG110) of June 30, 2018. A new record is added to reflect that the new health home entity is Evergreen Health and has the same HEALTH-HOME-SPA-PARTICIPATION-EFF-DATE (ELG109) of December 1, 2016.

Table 1 - HEALTH-HOME-SPA-PARTICIPATION-INFORMATION-ELG00006 Example

Health Home Providers in the HEALTH-HOME-SPA-PROVIDERS-ELG00007 segment

The HEALTH-HOME-SPA-PROVIDERS-ELG00007 file segment is used to identify a beneficiary’s health home provider. Any beneficiaries reported on the HEALTH-HOME-SPA-PARTICIPATION-INFORMATION-ELG00006 segment should have at least one record reported on the HEALTH-HOME-SPA-PROVIDERS-ELG00007 file segment of the eligible file. The values reported in the HEALTH-HOME-SPA-NAME (ELG118) and HEALTH-HOME-ENTITY-NAME (ELG119) data elements should match the values reported in those fields on the HEALTH-HOME-SPA-PARTICIPATION-INFORMATION-ELG00006 segment for the same beneficiary.

The health home provider’s state-assigned identification number should be reported in the HEALTH-HOME-PROV-NUM (ELG119) field. This state-assigned provider number should link to the SUBMITTING-STATE-PROV-ID field on the Provider File. The dates that the beneficiary is enrolled with a Health Home Entity should be reported in the HEALTH-HOME-SPA-PROVIDER-EFF-DATE (ELG121) field and HEALTH-HOME-SPA-PROVIDER-END-DATE (ELG122) field. Table 2 below provides a truncated example of how a beneficiary’s records should be reported if their health home entity changes. For the beneficiary reported MSIS ID 123456, the date of 6/30/2018 reported in HEALTH-HOME-SPA-PROVIDER-END-DATE (ELG122) is reported on the record with Community Care reflecting the beneficiary’s last day of enrollment with the health home entity. A new record is reported with a 7/1/2018 HEALTH-HOME-SPA-PROVIDER-EFF-DATE (ELG121) to capture the first day of the beneficiary’s participation with their new health home entity.

Table 2 - HEALTH-HOME-SPA-PROVIDERS-ELG00007 Example

If a health home participant has a team of providers, then all the providers on the team should be reported on the HEALTH-HOME-SPA-PROVIDERS-ELG00007 segment. A record segment would be reported for each of the providers on the team.^[5] Please see table 2 under MSIS ID 654321 for a truncated example how to report more than one provider on the HEALTH-HOME-SPA-PROVIDERS-ELG00007 segment.

Health Home Chronic Conditions

The HEALTH-HOME-CHRONIC-CONDITION-ELG00008 file segment is used to report the beneficiary’s chronic condition(s) that qualifies for participation in the health home program. Any beneficiaries reported on the HEALTH-HOME-SPA-PARTICIPATION-INFORMATION-ELG00006 segment should have at least one record reported on the HEALTH-HOME-CHRONIC-CONDITION-ELG00008 file segment of the eligible file. The HEALTH-HOME-CHRONIC-CONDITION (ELG130) should be populated with one of the valid values identified in the T-MSIS data dictionary (see table 3 for a list of the valid values). Some beneficiaries are eligible to participate in a health home because they have two or more chronic conditions. Each chronic condition identified by a unique T-MSIS valid value should be reported as a unique record for that beneficiary. If states have designated a health home chronic condition of “other” (HEALTH-HOME-CHRONIC-CONDITION (ELG130) = “H” (Other), then they should also provide an explanation of the other chronic condition in the HEALTH-HOME-CHRONIC-CONDITION-OTHER-EXPLANATION (ELG131) data element, which is a free text field. To find the list of other chronic conditions in each HH program in your state, search for “Population Criteria” in the approved SPA and see the condition names and descriptions listed in the “other” category. Note that there may be more than one set of other chronic conditions: (1) for individuals who qualify on the basis of two chronic conditions, and (2) for those who qualify on the basis of one chronic condition and the risk of developing another.

Table 3. Required Health Home Chronic Conditions to Populate in T-MSIS

If a beneficiary changes their health home entity enrollment on HEALTH-HOME-SPA-PARTICIPATION-INFORMATION-ELG00006 and HEALTH-HOME-SPA-PROVIDERS-ELG00007 segments, new records should be reported on HEALTH-HOME-CHRONIC-CONDITION-ELG00008 segment under the new health home entity for each of the beneficiary’s health home chronic conditions. All of the records reported under the previous health home entity should be reported with a HEALTH-HOME-CHRONIC-CONDITION-END-DATE value that reflects the last day of the beneficiary’s enrollment. The records reported under the new health home entity should be reported with a HEALTH-HOME-CHRONIC-CONDITION-EFF-DATE that reflects the first date of the beneficiary’s enrollment with that entity. 

Health Home Providers in the PROV-AFFILIATED-PROGRAMS-PRV00009 Segment

A health home provider’s participation in a health home program should be documented in the PROV-AFFILIATED-PROGRAMS-PRV00009 segment of the provider file. The name of the health home entity should be reported in the AFFILIATED-PROGRAM-ID (PRV120) field. If the provider is identified on the HEALTH-HOME-PROVIDERS-ELG00007 file segment, the state-assigned provider number reported in the HEALTH-HOME-PROV-NUM (ELG119) should match the state-assigned identifier reported in the SUBMITTING-STATE-PROV-ID (PRV118) field on the PROV-AFFILIATED-PROGRAMS-PRV00009 segment. The record segment that identifies the provider’s affiliation with a health home entity should be reported with an AFFILIATED-PROGRAM-TYPE (PRV119) value of “4” (Health Home Entity). In addition, the health home entity name that is reported in the HEALTH-HOME-ENTITY-NAME (ELG119) field should match with the health home entity name that is reported in the AFFILIATED-PROGRAM-ID (PRV120) field.

Table 4. HEALTH-HOME-PROVIDERS-ELG00007 Example Records

Table 5. PROV-AFFILIATED-PROGRAMS-PRV00009 Example Records

In Table 4 and Table 5, a simplified example of the linking requirements is provided using records from the HEALTH-HOME-PROVIDERS-ELG00007 segment of the eligible file and the PROV-AFFILIATED-PROGRAMS-PRV00009 segment of the provider file. On the HEALTH-HOME-PROVIDERS-ELG00007 segment reported in Table 2, the beneficiary with MSIS ID “77895” participates the health home program with Evergreen Behavioral Health Clinic. The state-assigned provider number for Evergreen Behavioral Health Clinic is “45690123”, which is used to link to the provider identifier in the Submitting State Provider ID field on the PROV-AFFILIATED-PROGRAMS-PRV00009 reported in Table 3. These records are both reported with the “Evergreen Behavioral Health Clinic Name” in the HEALTH-HOME-ENTITY-NAME (ELG119) field and the AFFILIATED-PROGRAM-ID (PRV120) field.

Reporting Health Home FFS Claims and Encounters

Fee-for-service (FFS) claims and managed care encounters that are related to one of the six health home services should be reported in the OT Claims file. 

• The information reported for a health home related claim on the OT header record should be the same as any other type of claim. For example, claims must have beneficiary information, provider information, diagnosis codes, payment fields, and other information. There are three data elements specific to health home claims that are reported at the header. 
  • HEALTH-HOME-PROV-IND (COT109) – A value of “1” (Yes) should be reported for health home related services. This indicator identifies if the claim is submitted by a provider or provider group participating in the health home program. 
  • HEALTH-HOME-ENTITY-NAME (COT138) – The name of the health home entity providing the health home service. This should match the HEALTH-HOME-ENTITY-NAME value reported for the same beneficiary on the eligible file. 
  • HEALTH-HOME-PROVIDER-NPI (COT146) – The national provider identifier for the health home provider. 
• Information reported for a health home related claim on the OT claim line detail should be the same as any other type of claim line record, except for two data elements. Claims for services provided to a beneficiary by their health home should have the following claim line detail fields populated as follows: 
  • BENEFIT-TYPE (COT209) – A value of “055” (Health Home Services) should be reported. This value identifies the service as a health home service.
  • XIX-MBESCBES-CATEGORY-OF-SERVICE (COT211) – A value of “43” (Health Home for Enrollees with Chronic Conditions) or “45” (Health Homes for Substance-Use-Disorder Enrollees per section 1006 of the SUPPORT for Patients and Communities Act) should be reported. This value identifies MBES category of service line on which health home services would be reported. 

Reporting PMPM Payments for Health Home Services

Most state Medicaid agencies pay health home providers a per-member per-month (PMPM) for delivery of health home services. These health home service payments should be reported using the capitation payment/PMPM type of claim value on the T-MSIS OT file. The information below provides information on how to report PMPM health home service payments on the OT file.

• The information reported for a care coordination and case management payment on the OT header record should be the same as any other any other record reported with a capitation payment/PMPM type of claim. For example, the PMPM payment must have beneficiary information, provider information, payment fields, and other information. The below information identifies specific reporting requirements for the care coordination and case management payment. 
  • TYPE-OF-CLAIM (COT037) – Report with a value of “2” to identify the record as a PMPM payment. 
  • HEALTH-HOME-PROV-IND (COT109) – A value of “1” (Yes) should be reported for health home related services. This indicator identifies that the payment is issued to a provider or provider group participating in the Health Home program. 
  • HEALTH-HOME-ENTITY-NAME (COT138) – The name of the health home entity providing the health home service. This should match the HEALTH-HOME-ENTITY-NAME value reported for the same beneficiary on the eligible file. 
  • HEALTH-HOME-PROVIDER-NPI (COT146) – The national provider identifier for the health home provider. 
  • BEGINNING-DATE-OF-SERVICE (COT033) and ENDING-DATE-OF-SERVICE (COT034) – These fields should be reported with the first date and last date of the period covered by the payment. 
• The information reported for a care coordination and case management payment on the OT line record should be the same as any other line record reported as part of a capitation payment/PMPM type of claim. The below information identifies specific reporting requirements at the line level for the care coordination and case management payment. 
  • BENEFIT-TYPE (COT209) – A value of “055” (Health Home Services) should be reported. This value identifies the service as a health home service.
  • XIX-MBESCBES-CATEGORY-OF-SERVICE (COT211) – A value of “43” (Health Home for Enrollees with Chronic Conditions) or “45” (Health Homes for Substance-Use-Disorder Enrollees per section 1006 of the SUPPORT for Patients and Communities Act) should be reported. This value identifies MBES category of service line on which health home services would be reported. 
  • TYPE-OF-SERVICE (COT186) - Report with a value of “138” is used to identify the PMPM payment for health home services. The TYPE-OF-SERVICE valid value of “138” will be added to the forthcoming version of T-MSIS Data Dictionary Appendix A. 
  • BEGINNING-DATE-OF-SERVICE (COT166) and ENDING-DATE-OF-SERVICE (COT167) – These fields should be reported with the first date and last date of the period covered by the payment.

Reporting Alternative Payment Methods for Health Home Services

States have the option to use alternative payment models for their health home programs^[6]. A state’s alternative payment model will likely be unique to the state’s program. As a result, the state should reach out to their state TA to determine how to accurately report the alternative payments in T-MSIS. 

A beneficiary’s enrollment in a health home program should not be reported on the MANAGED-CARE-PARTICIPATION-ELG00014 segment. Specifically, a beneficiary participating in a health home program should not be reported with a MANAGED-CARE-PLAN-TYPE (ELG193) value of “70”. A beneficiary’s participation in a health home program should instead be reported on the HEALTH-HOME-SPA-PARTICIPATION-INFORMATION-ELG00006 segment. Similarly, no records should be reported on the MANAGED-CARE-MAIN-MCR00002 segment with a MANAGED-CARE-PLAN-TYPE (MCR024) value of “70”. The managed care plan type value of “70” will be removed from future versions of the data dictionary. 

In some cases, states use a managed care organization for the delivery of health home services. If a managed care plan (either a comprehensive managed care plan or a prepaid health plan) furnishes health home services directly to the beneficiary or the managed care plan contracts with the health home provider, the guidance for reporting information on the eligible file, provider file, and reporting services on the OT file in the first section above does not change. In cases where a managed care entity is the health home entity, the managed care organizations should be identified in the three health home file segments reported on the eligible file. The beneficiary’s enrollment in the managed care plan would be document in the MANAGED-CARE-PARTICIPATION-ELG00014 segment as a comprehensive plan or as a prepaid health plan. As noted above, beneficiary’s enrollment in the managed care plan would not be reported with the deprecated “health home” MANAGED-CARE-PLAN-TYPE (ELG193) value. 

However, how the PMPM payment for health home services is documented may differ when reported by a managed care organization. In most cases, it is expected that the PMPM payment for health home services would be built into the capitation payment to the managed care organization. If the PMPM payment for health home services can be distinguished from the larger capitated payment for other health care services, then the payment should be reported on the capitation payment record as a distinct line record reported on the CLAIM-LINE-RECORD-OT-COT00003 segment of the capitation payment to the managed care organization. The PMPM payment for health home services line record should be reported with similar information as the capitation payment with the following data elements being reported distinctly. 

• BENEFIT-TYPE (COT209) – A value of “055” (Health Home Services) should be reported. This value identifies the service as a health home service.
• XIX-MBESCBES-CATEGORY-OF-SERVICE (COT211) – A value of “43” (Health Home for Enrollees w Chronic Conditions) or “45” (Health Homes for Substance-Use-Disorder Enrollees per section 1006 of the SUPPORT for Patients and Communities Act) should be reported. This value identifies MBES category of service line on which health home services would be reported. 
• TYPE-OF-SERVICE (COT186) - Report with a value of “138” is used to identify the PMPM payment for health home services. The TYPE-OF-SERVICE valid value of “138” will be added to the forthcoming version of T-MSIS Data Dictionary Appendix A. 
• BEGINNING-DATE-OF-SERVICE (COT166) and ENDING-DATE-OF-SERVICE (COT167) – These fields should be reported with the first date and last date of the period covered by the payment. 
• MEDICAID-PAID-AMT (COT178) – Report the health home services PMPM payment. 

If your health home program is integrated into managed care plans, you are encouraged to reach out to your state TA if your program structure may require adjustments to the reporting described in the sections above.

This document outlines the challenges states have faced when reporting eligibles enrolled in an Alternative Benefit Plan (ABP) in their T-MSIS submissions and recommends guidance for states’ reporting.

The Deficit Reduction Act of 2005^[1] modified Section 1937 of the Social Security Act^[2] to offer states new Medicaid benchmark and benchmark-equivalent benefit package options, affording states more flexibility in designing Medicaid benefit packages for specific populations. Now known as Alternative Benefit Plans (ABPs), these plans predominantly cover childless adult Medicaid-expansion populations (that is the VIII group) as specified under the Affordable Care Act, but states have and continue to use them as a coverage option for other eligibility groups. States can carefully target the needs of specific populations by offering multiple ABPs, each suited to the needs of the eligible populations. ABPs can be administered via one or more delivery systems including fee-for- service Medicaid, Medicaid managed care, and commercial insurance.

It is important to identify individuals enrolled in an ABP so they can be distinguished from other Medicaid eligibles who have either a broader or more limited benefit package. Limited options exist in T-MSIS for identifying ABP eligibles and their associated claims; therefore, it is important to use the few options that are available consistently and accurately. Since enrollment in ABPs is voluntary for some populations, demographics and eligibility criteria are not always specific enough to reliably identify ABP enrollees. If a state offers multiple ABPs to overlapping populations, it is also important to identify the specific ABP in which an eligible is enrolled.

If eligibles are enrolled in an ABP, then the ABP is their default Medicaid benefit plan, including optional wraparound services, so the ABP would cover all of their claims. Therefore, flagging the claims as ABP is redundant when eligibility information for eligibles enrolled in an ABP can reliably be linked to claims.

When identifying an ABP eligible, it is important to consider five data elements:

In the ELIGIBLE file, for adult Medicaid Expansion eligibles who are not medically frail:

• RESTRICTED-BENEFITS-CODE should be set to “7” (Individual is eligible for Medicaid and entitled to Medicaid benefits under an alternative package of benchmark-equivalent coverage, as enacted by the Deficit Reduction Act of 2005.)
• STATE-PLAN-OPTION-TYPE should be set to “06” (1937 (Alternative Benefit Plans))
• STATE-SPEC-ELIG-GROUP should indicate the ABP subpopulation and/or the eligible’s specific benefit package.
• ELIGIBILITY-GROUP for most ABPs is primarily the adult expansion population defined by values “72”, “73”, “74”, and “75”

In the ELIGIBLE file, for adult Medicaid Expansion eligibles who are medically frail and who have opted for the full-Medicaid benefit APB rather than the limited/restricted ABP available to non-medically frail adult Medicaid expansion eligibles:

• RESTRICTED-BENEFITS-CODE should be set to “1” (Individual is eligible for Medicaid or CHIP and entitled to the full scope of Medicaid or CHIP benefits).
• STATE-PLAN-OPTION-TYPE should be set to “06” (1937 (Alternative Benefit Plans))
• STATE-SPEC-ELIG-GROUP should indicate the ABP subpopulation and/or the eligible’s specific
• benefit package.
• ELIGIBILITY-GROUP for adult Medicaid Expansion eligibles who are medically frail are defined by values “72”, “73”, “74”, and “75”

In the MANAGED CARE PLAN file:

• OPERATING-AUTHORITY should be set to “10” (1937benchmark benefit program—programs to provide benefits that differ from Medicaid state plan benefits using managed care and implemented through the state plan) if the ABP is delivered through a managed care plan.

Adult Medicaid expansion eligibles who are not medically frail are required to be covered by an alternative benefit plan, as opposed to some other set of benefits such as full-Medicaid benefits. For adult Medicaid expansion eligibles who are medically frail, they must be given the option to choose either the limited/restricted ABP available to the adult Medicaid expansion population that is not medically frail or the full-Medicaid benefit APB.^[3] Therefore, all eligibles that are not medically frail reported with ELIGIBILITY- GROUP values “72”, “73”, “74”, or “75” (all representing adult Medicaid expansion populations) are expected to be reported with RESTRICTED-BENEFITS-CODE “7” and STATE-PLAN-OPTION-TYPE “06”. Adult Medicaid expansion eligibles who are medically frail and who have opted for the full-Medicaid benefit APB reported with ELIGIBILITY-GROUP values “72”, “73”, “74”, or “75” (all representing adult Medicaid expansion populations) are expected to be reported with RESTRICTED-BENEFITS-CODE “1” and STATE-PLAN-OPTION-TYPE “06”.

To ensure that all ABP-eligibles are properly captured in the data, states implementing expansions through 1115 waivers should follow these same coding guidelines for RESTRICTED-BENEFITS-CODE and STATE-PLAN-OPTION-TYPE. This is recommended even though these waiver enrollees might otherwise be mapped to RESTRICTED-BENEFITS-CODE ‘1’ or ‘5’ (due to the greater flexibility under the waiver) and STATE-PLAN-OPTION- TYPE would otherwise not be applicable.

As of February 2017 there are six states (IA, ID, IN, KY, MA, and MT) with multiple ABPs. Those six states should carefully consider how they can use the STATE-SPEC-ELIG-GROUP to distinguish under which specific ABP an individual is covered. CMS is considering future changes to the T-MSIS layout to capture this in a more uniform manner.

The following table lists relevant excerpts from the T-MSIS data dictionary pertaining to the five germane data elements.

Note: The specified valid values for RESTRICTED-BENEFITS-CODE, STATE-PLAN-OPTION-TYPE, and OPERATING-AUTHORITY all represent the same thing – applicability of Alternative Benefit Plan’s defined by Social Security Act Section 1937.

On September 16, 2016, CMS issued guidance to states to begin reporting Money Follows the Person (MFP) participation and services records in T-MSIS starting January 1, 2017. That guidance included a crosswalk from the legacy MFP reporting format to the T-MSIS data elements to facilitate this reporting. This T-MSIS guidance document provides additional information to support the T-MSIS reporting team inclusion of this data in monthly reporting.

States have been reporting MFP program participation and services data to CMS since the program’s inception in 2007. Since the formal evaluation will conclude at the end of September 2017, CMS provided guidance to the state MFP grantees to work with their state’s T-MSIS teams to include data in monthly T-MSIS reporting. This collaboration reduces state reporting burden to CMS and supports the development of a single, national data source for state Medicaid data. 

The September 2016 guidance indicates that MFP grantees should start reporting MFP participation and MFP service records in T-MSIS files by no later than January 1, 2017. This means all MFP transitions that occur on or after January 1, 2017 and all services financed with MFP grant funds should be reported in the state T-MSIS data files. Further, the guidance documents provide MFP program staff guidance about how states are to report participation in the MFP demonstration and the claims associated with the community-based long-term services and supports that are financed with MFP grant funds in these new T-MSIS files. The crosswalk that accompanies it (see Appendix C: Crosswalk of MFP File Data Elements to T-MSIS File Data Elements (PDF, 353.79 KB)) is more technical and designed for use by the T-MSIS team and state staff directly involved in the construction of state T-MSIS files.

The list of states awarded MFP grant funding is accessible on the Money Follows the Person page on Medicaid.gov.

State T-MSIS and MFP grantee staffs should jointly review historical MFP reporting to CMS and devise approaches to report the data in T-MSIS, if not currently having done so. The collaboration between the T-MSIS technical team and the MFP grantee staffs is critical for successful reporting in T-MSIS, like it is for all policy areas. CMS expects the quality of the data submitted to T-MSIS to be the same as or better than historical reporting to CMS. The appendices to this guidance include three documents that have previously been made available to MFP program staff. Appendix A (PDF, 156.06 KB) provides an overview of reporting MFP rebalancing program participation in T-MSIS, Appendix B (PDF, 174.69 KB) includes frequently asked questions on reporting MFP enrollment and service records in T-MSIS, and Appendix C (PDF, 353.79 KB) is a crosswalk of MFP file data elements to T-MSIS file data elements. Please review these appendices of existing MFP guidance and reach out to your T-MSIS TA if you have further questions.

The data captured in T-MSIS is valuable for researchers who are building and evaluating innovation models.  It provides researchers with historical data on model participants, as well as control data to compare against.  As researchers began to use the T-MSIS data, several shortcomings were noted. It can be difficult to link data collected independently of T-MSIS with data residing in T-MSIS for many states. A major factor causing this challenge is that some states do not use a Medicaid beneficiary’s Medicaid Card ID as their MSIS-IDENTIFICATION-NUM in T-MSIS. Beneficiary identifiers in T-MSIS (i.e., the MSIS-IDENTIFICATION-NUMs) are also subject to change.

Currently in T-MSIS, states report four types of eligible identifiers: (1) Medicare Health Insurance Claim Numbers (HICNs); (2) Medicare Beneficiary Identifiers (MBIs); (3) Social Security Numbers (SSNs); and (4) MSIS Identification Numbers (MSIS IDs).  Some states do not use a beneficiary’s Medicaid Card ID as the MSIS-IDENTIFICATION-NUM on their T-MSIS submissions therefore some researchers need a dedicated field for capturing Medicaid Card ID to be able to track T-MSIS data back to its various sources. CMS is introducing a new record segment (“ELG-IDENTIFIERS-ELG00022”) in the T-MSIS Eligible file to enable linking and managing effectively of the various identifiers associated with a beneficiary over the course of his/her involvement with the Medicaid/CHIP programs.

Some uses for this new segment are:

• States will use this segment to report each Medicaid and CHIP beneficiary’s Medicaid Card ID and the active time period for the corresponding identifiers. 
• States will also use this segment to report changes in a beneficiary’s MSIS Identification Number due to disenrollment/re-enrollment, record merges, large system enhancements, and transition from CHIP enrollment to Medicaid enrollment or from Medicaid enrollment to CHIP enrollment.

By capturing additional information and potential identifier changes over time, the new segment will allow CMS and researchers to better link identifiers and merge the beneficiary into one entity. The guidance in this brief defines the layout of the ELG-IDENTIFIERS-ELG00022 segment and each type of eligible identifier captured in T-MSIS and provides a high-level description of how states’ source systems can validate eligible identifier values for reporting in T-MSIS.

The new record segment, ELG-IDENTIFIERS (ELG00022), captures the identifiers assigned to a beneficiary by various entities.

This segment is critical for linking across data sources over time. The new ELG-IDENTIFIER-TYPE (ELG261) data element is used to identify whether the segment is reporting a beneficiary’s state-assigned Medicaid Card ID, Old MSIS Identification Number.  The state should provide the appropriate ELG-IDENTIFIER-TYPE code and supply the associated ID in the ELG-IDENTIFIER data element. Table 1 below shows the layout for the ELG-IDENTIFIERS-ELG00022 segment.

Table 1: Record Segment Layout for ELG-IDENTIFIERS-ELG00022

The following data elements are the record segment keys of ELG-IDENTIFIERS-ELG00022 segment

1. SUBMITTING-STATE
2. MSIS-IDENTIFICATION_NUM
3. ELG-IDENTIFIER-TYPE
4. ELG-IDENTIFIER
5. ELG-IDENTIFIER-EFF-DATE

As shown in Figure 1, the ELG-IDENTIFIERS-ELG00022 segment is a child to the PRIMARY-DEMOGRAPHICS-ELIGIBILITY-ELG00002 segment and links to that segment by the required data elements SUBMITTING-STATE, MSIS-IDENTIFICATION-NUM. Each record in the ELG-IDENTIFIERS-ELG00022 segment must have corresponding records in the PRIMARY-DEMOGRAPHICS-ELIGIBILITY-ELG00002 segments that contain effective and end-date ranges that span the effective and end-date range reported in the ELG-IDENTIFIERS-ELG00022 segment.

Critical fields that can be used to assess the validity of the ELG-IDENTIFIERS-ELG00022 segment information include ELG-IDENTIFIER-EFF-DATE (ELG263), ELG-IDENTIFIER-END-DATE (ELG264), ELG-IDENTIFIER-TYPE (ELG261), ELG-IDENTIFIER (ELG265) and REASON-FOR-CHANGE(ELG266). This section reviews these fields.

ELG-IDENTIFIER-EFF-DATE is a required field and represents the first day of the time span during which the values in all data elements in the ELG-IDENTIFIERS-ELG00022 segment are in effect. ELG-IDENTIFIER-EFF-DATE must be a valid date and populated in CCYYMMDD format. 

ELG-IDENTIFIER-END-DATE represents the last day of the time span during which the values of the data elements in the ELG-IDENTIFIERS-ELG00022 segment are in effect.

ELG-IDENTIFIER-TYPE is a code that identifies the kind of identifier captured in the ELG-IDENTIFIER data element. For every unique combination of SUBMITTING-STATE and MSIS-IDENTIFICATION-NUM, states should provide to T-MSIS the identifiers associated with the beneficiary for ELG-IDENTIFIER-TYPE 1 always and ELG-IDENTIFIER-TYPE 2 whenever it is applicable to the beneficiary.  If a beneficiary has multiple identifiers for the same ELG-IDENTIFIER-TYPE, then a separate record segment should be reported for each identifier.  For example, if a beneficiary has two old MSIS Identification Numbers, then a separate record segment for each of the old MSIS Identification Numbers should be reported with an ELG-IDENTIFIER-TYPE of “2” and their respective effective and end dates.  Table 2 below shows the valid values and associated descriptions.

Table 2: ELG-IDENTIFIER-TYPE Values

REASON-FOR-CHANGE is a code that identifies the reason for changing the MSIS-IDENTIFICATION-NUM of a beneficiary. This is applicable for ELG-IDENTIFIER-TYPE = 2, (Old MSIS Identification Number). For example, MSIS-IDENTIFICATION-NUM of a beneficiary is being changed due to 'Merge with other MSIS ID' or 'Unmerge'. Table 3 below shows the valid values and associated descriptions.

Table 3: REASON-FOR-CHANGE Values

States should work with their eligibility determination system to ensure that they implement the following best practices when assigning identifiers to beneficiaries during enrollment.

1. The ELG-IDENTIFIERS-ELG00022 data segment is being populated correctly.
2. Using the external resources that are available, the state should validate beneficiary’s identifiers during the enrollment process. Table 2 above shows available data sources by ELG-IDENTIFIER-TYPE. When preparing T-MSIS files, states should determine whether the identifiers comply with the stated validation criteria. If they do not, states should coordinate with the MMIS vendor to ensure that the data are being properly captured in the source systems.
3. States should adhere to the ELG-IDENTIFIERS-ELG00022 coding requirements as stated below and in Table 4.

Table 4: Coding Guidance

Example1: Reporting Medicaid Card ID of a Medicaid and CHIP beneficiary to T-MSIS

Regardless of whether or not a state uses the same value as both the Medicaid Card ID and the MSIS Identification number, it still must generate an ELG00022 segment that identifies the value as a Medicaid Card ID.  Table 5 shows an example where the values for both the Medicaid Card ID and MSIS Identification Number are the same, while Table 6 shows an example where the values are different.

Table 5: ELG-IDENTIFIERS-ELG00022 Example1 State submitting Medicaid Card ID and MSIS-IDENTIFICATION-NUM same

Table 6: ELG-IDENTIFIERS-ELG00022 Example1 State submitting Medicaid Card ID and MSIS-IDENTIFICATION-NUM different

Example2: Reporting Multiple MSIS IDs of a Medicaid and CHIP beneficiary to T-MSIS when state changes MSIS ID of a beneficiary

A state has reported two beneficiaries with MSIS ID M001 and M003 in the Eligible file. Later, the state identifies that those two beneficiaries are the same person therefore they want to merge the two MSIS IDs into one record. The most recent MSIS ID is M003 and the old MSIS ID is M001. The state should report that information in the new segment as follows:

Table 7: ELG-IDENTIFIERS-ELG00022 Example2

Example3: Reporting correct MSIS ID of a Medicaid and CHIP beneficiary to T-MSIS when state changes MSIS ID of a beneficiary.

A state has reported a beneficiary with MSIS ID M002 in the Eligible file. Later, the state identifies that they were reporting two beneficiaries’ information under the same MSIS ID (e.g., twin baby information) and then unmerged those two individuals. A new Medicaid Card ID and MSIS ID (M004) is assigned to twin baby B and the existing MSIS ID M002 will be used by twin baby A. The state should report the information in the new segment as follows:

Table 8. Reporting MSIS ID Changes

This reporting reminder provides background information and direction for states in reporting the ELIGIBILITY-GROUP (ELG087) data element for the Medicaid Expansion population in the T-MSIS Eligible file (ELIGIBILITY-GROUP valid values “72” through “75”)^[1].

• ELIGIBILITY-GROUP (ELG087)

• States should assign T-MSIS eligibility groups for their Medicaid expansion population using the T-MSIS Eligible file data element ELIGIBILITY-GROUP (ELG087) consistent with how they are assigned for the purposes of state’s reporting to the MBES.
• States should seek additional specific guidance via the State Data Quality Technical Assistance (DQ TA) team regarding specific requirements for reporting. However, some general background to inform the usage of T-MSIS Eligibility Groups 72-75 follows from Appendix F of the T-MSIS version 2.3 Data Dictionary:

This guidance specifies state reporting expectations for Transformed Medicaid Statistical Information System (T-MSIS) claims data for COVID-19 testing and testing-related services for uninsured individuals who receive limited Medicaid coverage for COVID-19 testing. Coronavirus Disease 2019, or COVID-19, is a respiratory disease caused by a novel coronavirus.^[1] The U.S. Secretary of Health and Human Services, Alex M. Azar II, declared a public health emergency as a result of confirmed cases of COVID-19 in the United States. The declaration is retroactive to January 27, 2020.^[2] This document provides guidance to states to report COVID-19 services in the T-MSIS Claims files.

Section 6004(a)(3) of the Families First Coronavirus Response Act (FFCRA) added Section 1902(a)(10)(A)(ii)(XXIII) to the Social Security Act (the Act).^[3] During any portion of the public health emergency period beginning March 18, 2020, this provision permits states to temporarily cover uninsured individuals through an optional Medicaid eligibility group for the limited purpose of COVID-19 testing. Such medical assistance, as limited by clause XVIII in the text following Section 1902(a)(10)(G) of the Act, includes: in vitro diagnostic products for the detection of SARS–CoV–2 or the diagnosis of the virus that causes COVID–19, and any visit for COVID–19 testing-related services for which payment may be made under the State plan. For the purposes of this eligibility group, please reference the COVID-19 FAQs on implementation of Section 6008 of the Families First Coronavirus Response Act and Coronavirus Aid, Relief, and Economic Security (CARES) Act for the definition of an uninsured individual.^[4] States can claim 100 percent FMAP for services provided to an individual enrolled in the COVID-19 testing group. The 100 percent match is only available for the testing and testing-related services provided to beneficiaries enrolled in the new COVID-19 testing group (and for related administrative expenditures).

While not directly applicable to Medicaid, the FFCRA (section 6001) defines testing-related services for group health plans and health issuers as “Items and services furnished to an individual during health care provider office visits (which term in this paragraph includes in-person visits and telehealth visits), urgent care center visits, and emergency room visits that result in an order for or administration of an in vitro diagnostic product described in paragraph (1), but only to the extent such items and services relate to the furnishing or administration of such product or to the evaluation of such individual for purposes of determining the need of such individual for such product.”^[5] Though not necessarily applicable to all Medicaid programs, Medicare uses HCPCS/CPT modifier “CS” to identify COVID-19 testing and testing-related services that are exempt from cost-sharing.^[6]

As states begin providing COVID-19 testing and testing-related services to uninsured individuals who receive limited Medicaid coverage for COVID-19 testing, states must accurately report this information in the T-MSIS Claims files. Without uniform reporting, it is difficult to analyze COVID-19 diagnostic products and testing-related services and expenditures. In addition, as things are changing rapidly, states are encouraged to periodically review the COVID-19 FAQs published by the Centers for Medicare and Medicaid Services.^[7]

To address the completeness and accuracy of reporting services for uninsured individuals who receive limited Medicaid coverage for COVID-19 testing and testing-related services, CMS has provided the following guidance to report services and expenditures in the T-MSIS Claims files. For current Medicaid and CHIP beneficiaries, states should map services and expenditures in the T-MSIS Claims files to the valid values for BENEFIT-TYPE, PROGRAM-TYPE, and TYPE-OF-SERVICE that would be used if the services weren't specifically for COVID-19 testing or COVID-19 testing-related services (for instance, using laboratory services). In addition, states who previously implemented the new T-MSIS values for COVID-19 reporting of claims for current Medicaid and CHIP beneficiaries will not need to resubmit their claims given this guidance update. States should make this change moving forward with their T-MSIS Claims files for existing Medicaid and CHIP beneficiaries. For uninsured individuals, it’s important for states to submit the new TYPE-OF-SERVICE, BENEFIT-TYPE, and PROGRAM-TYPE valid values as far back as is applicable to the uninsured population. Some states may need to fix and resubmit for claims for uninsured individuals.

There are three data elements in the T-MSIS Claims files that states should use to report COVID-19 diagnostic products and testing-related services: BENEFIT-TYPE (CIP268, CLT218, COT209, CRX148), PROGRAM-TYPE (CIP129, CLT079, COT065, CRX055), and TYPE-OF-SERVICE (CIP257, CLT211, COT186, CRX134). Table 1 shows the changes to the valid values for these data elements. These changes will be incorporated into the T-MSIS data dictionary at a future date but should be implemented by states immediately.

Table 1. T-MSIS Data Dictionary new valid values and descriptions to capture COVID-19 diagnostic products and testing-related services for uninsured individuals who receive limited Medicaid coverage for COVID-19 testing (to be implemented by states immediately)

There are data elements captured at both the header and line level on the Claims files that should be reported for uninsured individuals who receive limited Medicaid coverage for COVID-19 testing and testing-related services. States should ensure that there is consistency across these data elements for COVID-19 reporting. For example, a claim for a COVID-19 test should be reported with TYPE-OF-SERVICE “136” and BENEFIT-TYPE “107” at the line level and PROGRAM-TYPE “17” at the header level of the claim.

• CLAIM-HEADER-RECORD- IP/LT/OT/RX- CIP00002/CLT0002/COT00002/CRX00002
  • PROGRAM-TYPE (CIP129, CLT079, COT065, CRX055): A value of “17” should be reported for any COVID-19 diagnostic product that is administered during any portion of the emergency period, beginning March 18, 2020, or COVID–19 testing-related services for which payment may be made under the State plan. PROGRAM-TYPE “17” should always be reported at the header level for claims for uninsured individuals who receive limited Medicaid coverage for COVID-19 testing and testing-related services.
• CLAIM-LINE-RECORD-IP/LT/OT/RX- CIP00003/CLT00003/COT00003/CRX00003
  • TYPE-OF-SERVICE (CIP257, CLT211, COT186, CRX134):
    • A value of “136” should be reported for any COVID-19 diagnostic product that is administered during any portion of the emergency period, beginning March 18, 2020, to an uninsured individual who receives limited Medicaid coverage for COVID-19 testing and testing-related services.
    • A value of “137” should be reported for any COVID–19 testing-related services provided to an uninsured individual who receives limited Medicaid coverage for COVID-19 testing and testing-related services for which payment may be made under the State plan.
  • BENEFIT-TYPE (CIP268, CLT218, COT209, CRX148):
    • A value of “107” should be reported for any COVID-19 diagnostic product that is administered during any portion of the emergency period, beginning March 18, 2020, to an uninsured individual who receives limited Medicaid coverage for COVID-19 testing and testing-related services.
    • A value of “108” should be reported for any COVID–19 testing-related services provided to an uninsured individual who receives limited Medicaid coverage for COVID-19 testing and testing-related services for which payment may be made under the State plan.

CMS recognizes that states have worked with their billing/policy staff to make changes to T-MSIS to report COVID-19 testing and testing-related services. Further COVID-19 guidance about other data elements such as XIX-MBESCBES-CATEGORY-OF-SERVICE (CIP270, CLT224, COT211, CRX150) and XXI-MBESCBES-CATEGORY-OF-SERVICE (CIP271, CLT225, COT212, CRX151) may follow. CMS has also updated validation rule logic in the Operational Dashboard to accept new CPT, HCPCS, ICD-10 and any other national standard codes used to identify COVID-19 related services.

Table 2 below provides suggested mapping of relevant procedure codes to program type, type of service, and benefit types codes. The codes below are provided as an initial starting point for procedure codes that would be expected to be reported for testing and testing-related services. States may also consider diagnosis codes in their mapping. Please note that states are not limited to only the procedure codes identified in Table 2 for testing and testing-related services if your state has identified additional services codes.

Table 2. Suggested mapping of new COVID-19 T-MSIS valid values and procedure codes for uninsured individuals who receive limited Medicaid coverage for COVID-19 testing