Submitting Adjustment Claims to T-MSIS

Brief Issue Description

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 evaluate the changes to a claim that occur throughout its life.

Background Discussion

Before delving into CMS' guidance on how to populate the ICN-ORIG and ICN-ADJ fields, some background discussion is needed on terminology and concepts.

What claim transactions should be submitted to T-MSIS?

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 Table 1, below. The actual disposition 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 processes (if applicable) and falls into one of the claim status categories in Table 1, the state should send the claim/encounter to T-MSIS.

If a claim flows through the adjudication and payment processes and falls 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 2 provides examples and CMS' expectations.

What is a claim family?

A "claim family" (a.k.a. "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.

Are there transactions impacting the cost of care that are not claims/encounters and therefore not subsect to the claims family algorithm?

In previous iterations of T-MSIS, the 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 caused issues for states who were trying to build the T-MSIS Claim Files as well as problems for downstream users trying to interpret the T-MSIS data. These transactions have now been split out of the claims data files and put into their own file type. There are currently nine distinct types of financial transactions:

FTX002 – Individual Capitation PMPM,

FTX003 – Individual Health Insurance Premium Payment,

FTX004 – Group Insurance Premium Payment,

FTX005 – Cost Sharing Offset,

FTX006 – Value-Based Payment,

FTX007 – State-Directed Payment,

FTX008 – Cost Settlement Payment,

FTX009 - FQHC Wrap Payment and

FTX095 - Miscellaneous Payment.

As additional types of financial transactions are identified, new record layouts will be created and incorporated into the Financial Transaction File.

The concept of a “claim family” does not apply to financial transactions. Each of these transactions stands on its own and does not constitute a subsequent transaction that replaces the earlier transaction. In essence, a given series of financial transactions of the same type making payment to or recoupment from a given payee are additive. Each transaction remains active in the T-MSIS database. Whereas only the most recent member of a claim in a claim family is active. (The superseded members of the claim family are all inactive.)

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 with the MCO. Rather than generating an adjustment transaction for the May 2024 capitation that reflects 995 enrollees, and which would need to be tied to the previous transaction through “claim family” logic, the June, 2024 capitation payment would be adjusted to reflect the recoupment of the capitation payment for the 5 enrollees paid erroneously to the MCO.

What alternatives are there for tying the members of a claim family together?

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 claims subsequently are created, the ICN assigned to the initial final adjudicated version of the claim/encounter is carried forward on every subsequent adjustment claim. Table 3 illustrates how the ICN-ORIG and ICN-ADJ values on the members of a claim family are populated when the original ICN approach is used.

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 4 illustrates how the ICN-ORIG and ICN-ADJ values on the members of a claim family are populated when the daisy-chain ICN approach is used.

How are ICN-ORIG and ICN-ADJ fields impacted when voids are submitted?

The primary purpose of void transactions (ADJUSTMENT-IND = 1) is to nullify a claim/encounter from T-MSIS when the state does not wish to replace it with an adjusted claim/encounter record. These records must have the same claim key data element values as the claim/encounter being voided. Dollar and quantity fields should be set to zero. There can be instances where a state populates these fields with a negative value or the original transaction amount. The ADJUDICATION-DATE on these records should be set to the date that the state voided the claim.

Refer to T-MSIS Coding Blog entry "Populating T-MSIS Claims File Data Elements on Void/Reversal/Cancel Records" for additional detailed information.

Table 5 illustrates an example of how the dollar and quantity fields on the members of a claim family are populated when the state wishes to void a claim.

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

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.

Rules for inserting claim transactions into the T-MSIS database

The following five data elements identify a particular claim transaction (i.e., this is the claim key):

1) submitting_state

2) icn_orig

3) icn_adj

4) adjudication_date

5) adjustment_ind

In the “daisy-chain” claims family algorithm, T-MSIS uses the explicit ordering of the chain to set the sequence number for each claim in a family.

In the "original ICN" claims family algorithm, T-MSIS uses the claim with a null ICN-ADJ value as the root claim for the family. For subsequent claims, T-MSIS sorts by the following fields, in order:

1) ADJUDICATION-DATE

2) MEDICAID-PAID-DATE

3) CHECK-EFF-DATE

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 claim 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) tms_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.

CMS Guidance

The state can use either the original ICN approach or the daisy-chain ICN approach to populate the ICN-ORIG field on each member of the claims family.

T-MSIS will group claim transactions into claim families as part of the ETL process.

How to use this guidance document

This guidance document is not intended to slow down or derail existing state development initiatives. The intent is to provide clarification and standardization across the nation in key areas raised by state partners. Should guidance introduce rework in ongoing development, please bring this to the attention of your TA and CMS analyst to direct you to the most appropriate path that minimizes impact to your progress.

Brief Issue Description

Some states have requested assistance with identifying where to find in the X-12 claim transaction sets the NPIs and taxonomy codes of providers who performed various roles associated with the claim/encounter.

Background Discussion

Definitions

Provider role – The function that a specific provider performed for a particular patient on specified dates of service, and which are contained on fee-for-service claims or reported on encounter records. The roles that CMS would like to track on T-MSIS claims are:

Admitting (attending) provider

Billing provider

Dispensing provider

Operating provider

Prescribing provider

Referring provider

Servicing (rendering) provider

Provider role information needed for the T-MSIS claim files can be extracted from the standard X-12 transactions. The five tables in the “CMS Guidance” section of this document provide T-MSIS-toX-12 crosswalks for each provider role. The five tables are:

Table A: Provider roles on T-MSIS CLAIMIP files and their corresponding locations on the X-12 transactions

Table B: Provider roles on T-MSIS CLAIMLT files and their corresponding locations on the X-12 transactions

Table C: Provider roles on T-MSIS CLAIMOT (facility claims) files and their corresponding locations on the X-12 transactions

Table D: Provider roles on T-MSIS CLAIMOT (professional claims) files and their corresponding locations on the X-12 transactions

Table E: Provider roles on T-MSIS CLAIMOT (dental claims) files and their corresponding locations on the X-12 transactions

Table F: Provider roles on T-MSIS CLAIMRX files and their corresponding locations on the X-12 transactions

In each table, the first column identifies the provider role. The second and third columns identify the specific T-MSIS record segments and data elements used to capture the NPI and taxonomy of the provider performing the specified role. The fourth, fifth, sixth, and seventh columns in tables “A” through “E” provide the X-12 transaction name, data element identifier, data element description and loop id that map to the T-MSIS data element. The fourth, fifth, sixth, and seventh columns in table “F” provide the segment name, field identifier, field name and definition of the applicable NCPDP D.0 data set fields.

CMS Guidance

Use tables “A” through “F” to map the provider roles that are contained in the T-MSIS claim record layouts to their corresponding X-12 standard transaction data elements.

If the T-MSIS data element does not exist in the X-12 transaction set (shown as “N/A” in the tables below), 8-fill, leave blank or space-fill the T-MSIS data element when building T-MSIS claim files.