RFI Browser

Back  RFI # 2162: Define CTX Business Unit 999

Formal vs. Informal Help Informal Formal


Joyce Petrucci


What is a CTX Business Unit"?
"X12 Purpose: Describes an event context in terms of the application or implementation contexts in force at the time the event occurred and the position in the EDI stream at which that context was activated"
This would appear that the business unit is "positional" within the transaction and if the error didn't occur within that "position" than no Business Unit should be sent.
We have a client stating that the CTX Business Unit is always required for every transaction regardless of where the errors occur.
Is the Business Unit the "positional relationship" at the "patient/subscriber/dependent" level?
Is the Business Unite the entire transaction itself? If yes, then which "patient/subscriber/dependent" should be in the CTX Business Unit if the error occurs above this position?

Submitter Assigned Keywords

CTX Business Unit 999


The CTX business unit is not required for every error reported on the 999 transaction. The 2100 Business Unit Identifier CTX situational rule states - "Required when the error reported in this IK3 loop is within a business unit and the business unit identifier is known by the submitter of the 999. If not required by this implementation guide, do not send." As such the 2100 CTX is not required if the error exists outside the defined position used for the transaction or if the submitter of the 999 is unable to associate the error's location to a specific instance of the defined business unit.

In the 999 acknowledgment for Healthcare Insurance (005010X231), the 2100 CTX Business Unit Identifier defines a data element that can be used as a reference point to more quickly locate an error within a file. The data element and the level which is used for this reference point is defined based on the type of transaction that was submitted. The business unit identifiers for each guide are listed in the table below. The business unit for each guide is the loop which contains the business identifier and all nested loops. In some instances, such as the 835 the business unit would be the entire transaction. In other cases, a transaction can contain multiple business units.

269Claim Inquiry Reference IdentificationLoop-ID 2000 TRN02
270Subscriber Trace Number or Dependent Trace NumberLoop-ID 2000C TRN02 or Loop-ID 2000D TRN02
271Subscriber Trace Number or Dependent Trace NumberLoop-ID 2000C TRN02 or Loop-ID 2000D TRN02
274Healthcare Provider Identification CodeLoop-ID 2100 NM109
275Patient Identification CodeLoop-ID 1000D NM109 or Loop-ID 1000C NM109
276Claim Status Tracking NumberLoop-ID 2200D TRN02 or 2200E TRN02
277Claim Status Tracking NumberLoop-ID 2200D TRN02 or 2200E TRN02
278Subscriber Name Identification CodeLoop-ID 2010C NM109
820Organization Summary Remittance Assigned Number or Individual Remittance Assigned Number2000A ENT01 or Loop-ID 2000B ENT01
834Subscriber IdentifierLoop-ID 2000 REF02
835Reassociation Trace NumberHeader TRN02
837Claim Submitter's IdentifierLoop-ID 2300 CLM01
Submission 7/1/2016
Status Date 4/3/2017
Status F - Final
Primary References
Document 005010X231
Set ID999
Segment IDCTX