Determine the mappings for claims or billing transaction fields

Background and Strategy

The general topic of transactional vs. "final action" format claims data, including how to determine the format of the source data, was first discussed in an earlier task, Determine the grain size of each source data object. The immediate prior task, Determine the mappings for identifier fields, discussed how to map local identifiers to the appropriate "Source Local" fields, including for claim and transaction identifiers. This task covers the (often challenging) exercise of identifying and mapping the other transaction-level fields needed to reconcile transactional claims or billing data to final action status.

(To clarify: this task is only relevant when integrating transactional claims or billing data. If the source data are "final action" format -- or if the data do not include any claims or billing data at all -- this task can be skipped.)

There are three potential subtasks:

1. If the source data do not contain an appropriate candidate for Source Local Claim ID or Source Local Bill ID, determine how to construct one from other available fields.

To reconcile a series of transactions and obtain a claim's final action status one must be able to identify all the transactions associated with that claim. Usually, the means to do this is provided in the source data in the form of an identifier for the claim. Sometimes, however, that field is absent, and in those circumstances a composite key must be cobbled together from the existing fields.

The ideal fields to include in this composite are claim-level fields that are unlikely to change over the lifetime of a claim (as it is potentially reversed and/or adjusted), but which are sufficiently specific to uniquely identify a claim. A reasonable composite to consider for this purpose is a 4-tuple comprising a patient identifier, a billing provider identifier, and the (header-level) covered start and end dates. Depending on the source data, it might be necessary to further disambiguate by including additional tokens, e.g., indicating whether the claim is institutional or professional, an identifier for the payor, or a Type of Bill code (for institutional claims).

As with natively occuring fields, this composite key should be mapped to Source Local Claim ID during semantic mapping.

2. Identify the field or fields that can be used to determine the order in which transactions were applied.

When reconciling the transactions on a claim, it’s important to know which transaction was last, because that will typically tell you something about the current state of the claim. (E.g., if the last transaction is a reversal, the entire claim or service line item can be considered reversed; and in some cases the allowed and paid amounts on the last transaction represents the final action quantities.)

In the simplest cases, the ordering is captured by a dedicated ordinal “sequence number” field. (Note that the sequence number can sometimes be embedded as a token in another field, e.g., as the last 3 digits of the transaction identifier.) More often, it is necessary to find a date or datetime field representing the moment the transaction was posted. When only a date (i.e., a date without a timestamp) is available, as is typically the case in a claims extract, a tiebreaker will be needed, since it is common for transactions to be made on the same calendar date. The transaction type is the standard tiebreaker to use in these circumstances, with the assumption that if two transactions are performed on the same day it’s likely the case that the reversal was performed first (to back out the existing information) followed by the non-reversal transaction (often described as an "adjustment").

The following fields in the Claims Transaction Fields Semantic Mapping Template are appropriate to capture the fields discussed above: Transaction Sequence Number, Transaction Effective Date, Transaction Effective Datetime, Transaction Type Operational ID, Is Adjustment Transaction, Is Reversal Transaction, and Is Non-Reversal Transaction. (This represents a superset of fields; not all of them will be needed in any one instance.)

3. Determine whether certain numeric fields represent the transaction's marginal change to a value or the resulting value post-transaction.

There are two prevailing conventions used to calculate final action amounts from transactional data: (1) consider the values on each transaction to represent the marginal change in the amount associated with that transaction, with the final action amount obtained by summing the values across all transactions; and (2) consider the value on the last transaction to represent the final action amount. (The first convention is much more common.)

To determine which convention is in use, it should suffice to look at a handful of reversal transactions and note whether the amounts – allowed amount or paid amount are good fields to use here – are zero or negative. Zero amounts imply convention (2), since the reversals typically bring the running total of a claim to zero; negative amounts imply convention (1), since the marginal increase in some amount effected by a reversal is nearly always negative.

The appropriate way to memorialize whichever convention is identified is to map each amount field in the source data to the correct template field. For example, to reflect convention (1), use fields like Increase to Allowed Amount, Increase to Plan Paid Amount, Increase to Service Unit Count, and Increase to Days Supply; and to reflect convention (2), use fields like Resulting Allowed Amount, Resulting Plan Paid Amount, Resulting Service Unit Count, and Resulting Days Supply.

Note that some source data systems will use positive numbers on reversals to describe reductions to the amount in question. The semantic convention in the Core Data Model is that all changes in amounts of this sort be expressed as increases (hence the field names above that use the word “increase” instead of the more ambiguous “change”). In other words, no matter what kind of transaction, a reduction should be reflected as a negative number (i.e., a negative “increase”); it is the responsibility of the semantic mapping process to enforce this convention.

Detailed Implementation Guidance

1. For mapping transactional claims data, note that there is a special template dedicated to mapping transaction-level information: Claims Transaction Fields.

Examples

Example 1: Transactional claim service line item data

The following table contains transactional claims data for two claims, one (clm_id = 10) with three service line items, the second (clm_id = 11) that starts with two service line items, one of which (line = 2) is reversed (by trx_clm_id = 1102) and never reapplied.

The standard mappings for a case like this would be as follows:

• Source Local Claim ID: clm_id
• Source Local Claim Service Line Item ID: a composite key of clm_id and line
• Source Local Claim Service Line Number: line
• Source Local Transaction Header ID: trx_clm_id
  • NB: if trx_clm_id didn’t exist, then the composite key of clm_id and trx_seq_no would also suffice)
• Source Local Transaction Service Line Item ID: trx_detail_id
  • NB: if trx_detail_id didn’t exist, then the composite key of clm_id, line, and trx_seq_no would also suffice)
• Transaction Sequence Number: trx_seq_no
• Increase to Plan Paid Amount: plan_paid
• Transaction Type Operational ID: trx_type
• Is Adjustment Transaction: if trx_type = "A" then 1, else 0
• Is Reversal Transaction: if trx_type = "R" then 1, else 0

These mappings would provide downstream objects with all the fields needed to correctly interpret the contents and reconcile to final action status.