CMS Technical Instruction: Populating T-MSIS Claims File Data Elements on Void/Reversal/Cancel Records

In T-MSIS, original claims may be adjusted to nullify, replace, or correct information included on the original claim. The reporting of these records that are voids/reversals/cancellations of previously submitted FFS claims and encounters is important for the accurate interpretation of records and identification of Medicaid utilization and expenditures in T-MSIS. Furthermore, 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] . Consistent reporting across states is necessary for accurate interpretation of the data. The following technical instruction document describes how the progression of adjudication should be reflected in T-MSIS submissions and addresses how to appropriately populate data elements on these adjudicated records.

Some states do not currently follow the requirements for reporting void/reversal/cancel records as specified in the T-MSIS data dictionary. This is particularly an issue for the reporting of 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.

Claim Family Reporting: Progression of submitting adjustment claims

A claim family (also known as an adjustment set) is defined as a set of post-adjudication claim transactions in paid or denied status that relate to the same provider/enrollee/services/dates of service. This grouping of the original claim and all its subsequent adjustment and/or void claims shows the progression of changes that have occurred since it was first submitted. Every “final” adjudicated version of the claim/encounter should be submitted to T-MSIS. A “final” adjudicated version of the claim/encounter is a claim that has completed the adjudication process and the paid/denied process. The claim and each claim line will have one of the finalized claim status categories listed in T-MSIS Data Dictionary. The actual position of the claim can be either “paid” or “denied”.

Both original claims (or encounters) and adjusted claims (or encounters) can be a “final adjudicated version of the claim/encounter.” Whenever a claim/encounter flows through the adjudication and payment process (if applicable) and falls into one of the claim status categories listed in the T-MSIS Data Dictionary., the state should send the claim/encounter to T-MSIS. If a claim flows through the adjudication and payment processes and flows into one of the finalized claim status categories multiple times within a single T-MSIS reporting period, CMS expects each of these final adjudicated versions of the claim/encounter to be submitted to T-MSIS, not just the one effective on the last day of the reporting period. If the claim has not been through the final adjudication process or is “pending” (or in “suspense”), the claim should not be sent to T-MSIS until disposition has been settled to one of the finalized claim status categories. Table 1 provides examples of CMS’ expectations.

Table 1 – Scenarios for When to Submit Original and Adjusted Claims

Approaches to tying the members of a claim family together

There are two ways original claims, and their subsequent adjustments can be linked into a claim family – either through all adjustments linking back to the original claim or each subsequent adjustment linking back to the prior claim (i.e., daisy chain). Identifying the members of a claim family is necessary to support accurate evaluation of claim lifecycle changes.

The Original ICN Approach - Under this approach, the state assigns an ICN to the initial final adjudicated version of the claim/encounter and records this identifier in the ICN-ORIG field. If adjustment claim subsequently are created, the ICN assigned to the initial final adjudicated version of the claim/encounter is carried forward on every subsequent adjustment claim.

The Daisy-Chain ICN Approach - Under this approach, the state records the ICN of the previous final adjudicated version of the claim/encounter in the ICN-ORIG field of the adjustment claim record. If additional adjustment claims are subsequently created, the ICN-ORIG on the new adjustment claim only points back one generation.

Table 2 provides examples of void claims linked to previous records using both the original ICN approach (rows 1 – 3) as well as 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 on claims and PAYMENT-OR-RECOUPMENT-DATEE^[a] and/or PAYMENT-DATE^[a] on financial transactions is populated accurately. The record in the claim family with the most recent ADJUDICATION-DATE, PAYMENT-OR-RECOUPMENT-DATE or PAYMENT-DATE will be identified as the most recent submission of the claim^[3].

Table 2 – Using record keys to link void claims to prior submissions

If a state uses a process to record adjustments whereby, they void the previous version of the claim and then follow-up with the creation of a new original transaction, and the state can identify that the void and the new original claim are from the same adjudication set, the state should link them together into one claims family using the ICN-ORIG. CMS recognizes that some states may not be able to link a resubmitted claim after a void to the original claim. Table 3 illustrates how CMS is expecting the states to populate the ICN-ORIG/ICN-ADJ fields when the state processes a void/new original when adjusting claims. CMS expects a void transaction to have a $0.00 dollar amount.

Table 3 – Void/New Original Scenario

Transactions impacting the cost of care that are not FFS claims or encounters: Financial Transactions (FTX)

In previous iterations of T-MSIS prior to v4, claim files were also used to capture expenditures that impacted the cost of care, but which were not technically claims or encounter records. These were referred to as “gross adjustments” and created challenges for states building T-MSIS Claims Files and for downstream users trying to interpret T-MSIS data. To address these challenges, these transactions were removed from the claims files and placed into their own file type. There are currently nine distinct types of financial transactions included in the FTX file. CMS does not expect any denied FTX claims to be reported to T-MSIS. The FTX file segments do not contain data or valid values to indicate a financial transaction is denied. Financial transactions can be reported as original, void, or (credit/debit) adjustments.

States may use the claims family algorithm in the same manner as claims or encounters for financial transactions. When states report financial transaction adjustments using related ICN values (through ICN-ORIG or ICN-ADJ) apply ADJUSTMENT-IND values of ‘1’ (Void) or ‘4’ (Replacement), T-MSIS processing will apply claim family logic to identify related transactions. In these cases, the most recent transaction completely voids or replaces the prior transaction, consistent with standard adjustment processing.

If a state does not employ the claims family algorithm, then each financial transaction stands on its own and remains active in the T-MSIS database, with multiple transactions of the same type being additive rather than superseding prior records. For example, states whose systems do not adjust transactions in sequence and do not completely void or replace prior transactions through ICN linkage, a beneficiary- or enrollee-specific recoupments with an ADJUSTMENT-IND value ‘0’ (Original) may be the only applicable value with a negative payment amount. While negative payment amounts are not typically expected on original transactions, they are appropriate when a financial transaction reflects a credit or recoupment and is not directly linked to a prior transaction that is fully voids or replaces.

For instance, a state pays a managed care entity a monthly capitation for 1,000 enrollees for the month of May 2024. In June 2024, it is determined that 5 of the enrollees included in the May 2024 capitation were, in fact, not enrolled in the MCO. Table 4 illustrates how a state may recoup the overpayment.

Table 4 – Capitation Recoupment Scenario

For additional information please refer to CMS Technical Instructions: Reporting Adjustment Indicator (ADJUSTMENT-IND) for Financial Transactions.

Populating Data Elements on Adjudicated Claims

The following section provides further information on how to populate data elements on void/reversal/cancel records in T-MSIS. While this primarily addresses reporting void/reversal/cancel records for FFS claims and encounters, it also applies to financial transactions like capitation payments that are adjusted using claim-based replace and void/reversal/cancel processes. Again, financial transactions reported in the FTX file may or may not follow claim family logic.

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 5.
• 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 6.
• Adjudicated quantity data elements should all be reported with a value of “0”. These data elements are identified in Table 7.
• 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 5, Table 6 or Table 7.

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 5a/5b. 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. The adjudication date, payment date, or recoupment 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. As previously discussed, 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 5a – Record Key Data Elements

Table 5b – Record Key Data Elements in the Financial Transactions File (FTX)

“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 6 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 6 – 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 7. 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 7 - Adjudicated Quantity Data Elements (Claims Files)

Note: States should populate MBESCBES-FORM-GROUP (CIP.003.340, CLT.003.28, COT.003.290, CRX.003.209) on voided or replacement claims (when Medicaid Paid Amount is $0 or less than $0).

Table 7b - Adjudicated Quantity Data Elements (FTX File)

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.

How Adjustment Records will be Applied by CMS

There is an inherent limitation in the way that CMS can interpret what to do with two claim transactions having the same ICN-ORIG and ADJUDICATION-DATE when both transactions are received in a single submission file. The processing rules that T-MSIS will follow are outlined below. It is up to each state to ensure that claim transactions are processed in the appropriate sequence. If the rules below do not result in the sequence of transactions that the state desires, it is up to the state to submit transactions in separate files so that the desired sequence is attained.

The following provides guidance on inserting claim transactions into the T-MSIS database. The five data elements below identify a particular claim transaction (i.e., this is the claim key)

• submitting_state
• icn_orig
• icn_adj
• adjudication_date
• adjustment_ind

Within the T-MSIS system, claim family IDs are composed of the hash of the ANSI submitting state id, file type, reporting period, sequence number, and byte offset of the claim in the family from the earliest (by date received) file and with the lowest byte offset within that file. Inactive versions of claims in the claims family (that is inactive records with the same record key as any of the active claims that compose the claims family) are included in the set of claims considered for generation of the claims family id. This ensures that even if the claim that is used to generate a claims family’s ID is subsequently updated, the claims family’s ID will remain stable. If two claims transactions have the same key, the active instance is determined by evaluating these data elements:

1. claim_header_reporting_period
2. claim_header_byte_offset
3. submitting_state
4. tmsis_run_id

Ties based on the above fields are broken by sorting on (a) reporting period of the file containing the claim, (b) sequence number of the file, and (c) byte offset of the claim within the file