276 Request Transaction Set Listing
008020X329 Health Care Claim Status Request and Response- Loop 2000A - INFORMATION SOURCE LEVELRequired1
- Loop 2100A - PAYER NAMERequired1
- Loop 2000B - INFORMATION RECEIVER LEVELRequired1
- Loop 2100B - INFORMATION RECEIVER NAMERequired1
- Loop 2000C - SERVICE PROVIDER LEVELRequired>1
- Loop 2100C - PROVIDER NAMERequired1
- Loop 2000D - SUBSCRIBER LEVELRequired>1
- Loop 2100D - SUBSCRIBER NAMERequired1
- Loop 2200D - CLAIM STATUS TRACE NUMBERSituational>1
- Loop 2210D - SERVICE LINE INFORMATIONSituational>1
- Loop 2000E - DEPENDENT LEVELSituational>1
- Loop 2100E - DEPENDENT NAMERequired1
- Loop 2200E - CLAIM STATUS TRACE NUMBERRequired>1
- Loop 2210E - SERVICE LINE INFORMATIONSituational>1
ISA - INTERCHANGE CONTROL HEADER
- For compliant implementations under this implementation guide, ISA13, the interchange Control Number, must be a positive unsigned number. Therefore, the ISA segment can be considered a fixed record length segment.
- The first element separator defines the element separator to be used through the entire interchange.
- Spaces in the example interchanges are represented by "." for clarity.
- The ISA segment terminator defines the segment terminator used throughout the entire interchange.
- All positions within each of the data elements must be filled.
- The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
- Must be a positive unsigned number and must be identical to the value in IEA02.
GS*HR - FUNCTIONAL GROUP HEADER
ST*276 - TRANSACTION SET HEADER
- This element must be populated with the implementation guide Version/Release/Industry Identifier Code named in Section 1.2.
- This element contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST/SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.
BHT*0010 - BEGINNING OF HIERARCHICAL TRANSACTION
- This element is to be used to trace the transaction from one point to the next point, such as when the transaction is passed from one clearinghouse to another clearinghouse.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
HL - INFORMATION SOURCE LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*PR - PAYER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
HL - INFORMATION RECEIVER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*41 - INFORMATION RECEIVER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
HL - SERVICE PROVIDER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*1P - PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
OR
Use when the provider is not in the United States or its territories and has received an NPI.
HL - SUBSCRIBER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
- When the patient is the subscriber or a dependent with a unique identification number, the claim status request information is reflected in the 2200D Loop under the Subscriber HL, 2000D Loop (HL03 = 22). The Dependent HL, 2000E Loop is not used. See Section 1.4.2.1 for more information on defining the patient.
- When requesting and responding to claim status for both a subscriber and dependent(s) of that subscriber without a unique ID, the Subscriber HL Loop 2000D must be followed by the subscriber's claim status data, Loop 2200D. In this instance, HL04=0 would be used. The Subscriber HL Loop 2000D must be repeated prior to one or more of the Dependent HL Loop 2000E and their corresponding claim status data, Loop 2200E. In this instance, Loop 2000D HL04=1 would be used. See Section 1.4.3.3 for an example of this structure.
DMG*D8 - SUBSCRIBER DEMOGRAPHIC INFORMATION
- P0102
If either DMG01 or DMG02 is present, then the other is required. - P1011
If either DMG10 or DMG11 is present, then the other is required. - C1105
If DMG11 is present, then DMG05 is required.
NM1*IL - SUBSCRIBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
TRN*1 - CLAIM STATUS TRACE NUMBER
- This segment conveys a unique trace or reference number for each 2200D loop. This number will be returned in the 277 response.
- When the patient is not the subscriber or a dependent with a unique identification number, the Loop 2200E TRN and subsequent segments will be used to reflect the claim status information.
REF*1K - PAYER CLAIM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF*BLT - INSTITUTIONAL BILL TYPE IDENTIFICATION
At least one of REF02 or REF03 is required.
- Concatenate the 837I CLM05-01 (Facility Type Code) and CLM05-03 (Claim Frequency Code) values.
Code Source 236: Uniform Billing Claim Form Bill Type
Code Source 235: Claim Frequency Type Code - Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF*6P - GROUP NUMBER
At least one of REF02 or REF03 is required.
REF*X1 - PROVIDER'S ASSIGNED CLAIM IDENTIFIER
At least one of REF02 or REF03 is required.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- For example, this is the value from CLM01 of an 837.
- The maximum number of characters to be supported for this qualifier is 35. Characters beyond the maximum are not required to be stored or returned by the receiving system.
REF*XZ - PHARMACY PRESCRIPTION NUMBER
At least one of REF02 or REF03 is required.
REF*D9 - CLAIM IDENTIFIER FOR TRANSMISSION INTERMEDIARIES
At least one of REF02 or REF03 is required.
REF*Y4 - PROPERTY & CASUALTY CLAIM NUMBER
At least one of REF02 or REF03 is required.
AMT*T3 - TOTAL CLAIM CHARGE AMOUNT
- Not all payer systems retain the original submitted charges. Charges are sometimes changed during processing.
- Use of this data as search criteria may vary by information source.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- The Total Claim Charge Amount must be greater than or equal to zero.
DTP*472 - SERVICE DATE
SVC - SERVICE LINE INFORMATION
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- This amount is the original submitted charge.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
REF*6R - LINE ITEM CONTROL NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
TOO - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
HL - DEPENDENT LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
DMG*D8 - DEPENDENT DEMOGRAPHIC INFORMATION
- P0102
If either DMG01 or DMG02 is present, then the other is required. - P1011
If either DMG10 or DMG11 is present, then the other is required. - C1105
If DMG11 is present, then DMG05 is required.
NM1*QC - DEPENDENT NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
TRN*1 - CLAIM STATUS TRACE NUMBER
REF*1K - PAYER CLAIM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF*BLT - INSTITUTIONAL BILL TYPE IDENTIFICATION
At least one of REF02 or REF03 is required.
- Concatenate the 837I CLM05-01 (Facility Type Code) and CLM05-03 (Claim Frequency Code) values.
Code Source 236: Uniform Billing Claim Form Bill Type
Code Source 235: Claim Frequency Type Code - Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF*6P - GROUP NUMBER
At least one of REF02 or REF03 is required.
REF*X1 - PROVIDER'S ASSIGNED CLAIM IDENTIFIER
At least one of REF02 or REF03 is required.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- For example, this is the value from CLM01 of an 837.
- The maximum number of characters to be supported for this qualifier is 35. Characters beyond the maximum are not required to be stored or returned by the receiving system.
REF*XZ - PHARMACY PRESCRIPTION NUMBER
At least one of REF02 or REF03 is required.
REF*D9 - CLAIM IDENTIFIER FOR TRANSMISSION INTERMEDIARIES
At least one of REF02 or REF03 is required.
REF*Y4 - PROPERTY & CASUALTY CLAIM NUMBER
At least one of REF02 or REF03 is required.
AMT*T3 - TOTAL CLAIM CHARGE AMOUNT
- Not all payer systems retain the original submitted charges. Charges are sometimes changed during processing.
- Use of this data as search criteria may vary by information source.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- The Total Claim Charge Amount must be greater than or equal to zero.
DTP*472 - SERVICE DATE
SVC - SERVICE LINE INFORMATION
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- This amount is the original submitted charge.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
REF*6R - LINE ITEM CONTROL NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
TOO - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
SE - TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
277 Response Transaction Set Listing
008020X329 Health Care Claim Status Request and Response- Loop 2000A - INFORMATION SOURCE LEVELRequired1
- Loop 2100A - PAYER NAMERequired1
- Loop 2200A - INFORMATION SOURCE APPLICATION TRACE IDENTIFIERSituational1
- Loop 2000B - INFORMATION RECEIVER LEVELRequired1
- Loop 2100B - INFORMATION RECEIVER NAMERequired1
- Loop 2200B - INFORMATION RECEIVER TRACE IDENTIFIERSituational1
- Loop 2000C - SERVICE PROVIDER LEVELSituational>1
- Loop 2100C - PROVIDER NAMERequired1
- Loop 2000D - SUBSCRIBER LEVELSituational>1
- Loop 2100D - SUBSCRIBER NAMERequired1
- Loop 2200D - CLAIM STATUS TRACE NUMBERSituational>1
- Loop 2210D - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATIONSituational1
- Loop 2220D - SERVICE LINE INFORMATIONSituational>1
- Loop 2225D - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATIONSituational1
- Loop 2000E - DEPENDENT LEVELSituational>1
- Loop 2100E - DEPENDENT NAMERequired1
- Loop 2200E - CLAIM STATUS TRACE NUMBERRequired>1
- Loop 2210E - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATIONSituational1
- Loop 2220E - SERVICE LINE INFORMATIONSituational>1
- Loop 2225E - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATIONSituational1
ISA - INTERCHANGE CONTROL HEADER
- For compliant implementations under this implementation guide, ISA13, the interchange Control Number, must be a positive unsigned number. Therefore, the ISA segment can be considered a fixed record length segment.
- The first element separator defines the element separator to be used through the entire interchange.
- Spaces in the example interchanges are represented by "." for clarity.
- The ISA segment terminator defines the segment terminator used throughout the entire interchange.
- All positions within each of the data elements must be filled.
- The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
- Must be a positive unsigned number and must be identical to the value in IEA02.
GS*HR - FUNCTIONAL GROUP HEADER
ST*277 - TRANSACTION SET HEADER
- This element must be populated with the implementation guide Version/Release/Industry Identifier Code named in Section 1.2.
- This element contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST/SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.
BHT*0010 - BEGINNING OF HIERARCHICAL TRANSACTION
- This identifier is the identifier received in the BHT03 of the corresponding 276 transaction.
- This information may be sent at the creator of the 277's discretion if using the transaction in a Batch mode. Due to the nature of batch transaction processing, the receiver of the 277 transaction (whether it is a clearinghouse or information source) may or may not be able to return the 276 BHT03 value in the 277 BHT03.
- This element is to be used to trace the transaction from one point to the next point, such as when the transaction is passed from one clearinghouse to another clearinghouse. This identifier is not to be passed through the complete life of the transaction, rather replaced with the identifier received in the 276.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
HL - INFORMATION SOURCE LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*PR - PAYER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
PER*IC - PAYER CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
TRN*1 - INFORMATION SOURCE APPLICATION TRACE IDENTIFIER
- This is a unique trace number that identifies a specific transaction. This number is assigned by the Information Source.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
HL - INFORMATION RECEIVER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*41 - INFORMATION RECEIVER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
TRN*2 - INFORMATION RECEIVER TRACE IDENTIFIER
- If reporting error status at this level, 2000C, 2000D and 2000E Loops are not used.
- See Section 1.4.4.2 Status Response Levels for additional information on reporting status at the Information Receiver level.
- This value must be the BHT03 data element value from the 276 Claim Status Request being rejected.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
STC - INFORMATION RECEIVER STATUS INFORMATION
- See Section 1.4.4 - Status Information (STC) Segment Usage for specific STC segment information related to the hierarchical level, composites and code use.
- If reporting error status at this level, 2000C, 2000D and 2000E Loops are not used.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
HL - SERVICE PROVIDER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*1P - PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
OR
Use when the provider is not in the United States or its territories and has received an NPI.
HL - SUBSCRIBER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
- When the patient is the subscriber or a dependent with a unique identification number, the claim status response information is reflected in the 2200D Loop under the Subscriber HL, 2000D Loop (HL03 = 22). The Dependent HL, 2000E Loop is not used. See Section 1.4.2.1 for more information on defining the patient.
- When requesting and responding to claim status for both a subscriber and dependent(s) of that subscriber without a unique ID, the Subscriber HL Loop 2000D must be followed by the subscriber's claim status data, Loop 2200D. In this instance, HL04=0 would be used. The Subscriber HL Loop 2000D must be repeated prior to one or more of the Dependent HL Loop 2000E and their corresponding claim status data, Loop 2200E. In this instance, Loop 2000D HL04=1 would be used. See Section 1.4.3.3 for an example of this structure.
NM1*IL - SUBSCRIBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
TRN*2 - CLAIM STATUS TRACE NUMBER
- When the patient is not the subscriber or a dependent with a unique identification number, the Loop 2200E TRN and subsequent segments will be used to reflect the claim status information.
- This is the trace or reference number from the originator of the transaction that was provided for this patient's 276 request.
STC - CLAIM LEVEL STATUS INFORMATION
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- All Category Codes except 'Request for Additional Information' (R Category Codes) are allowable at this level.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject Codes may be used for status related to pharmacy claims. When these codes are used, STC01-04 must have the value 'RX'.
- The total claim charge may change from the submitted claim total charge based on claims processing instructions, i.e. claim splitting. Some payers may not store the original submitted charge. Some HMO encounters supply zero as the amount of original charges.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- Zero is an acceptable amount when no payment is being made.
- Some payers are able to provide the adjudicated payment amount prior to the remittance being issued.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- This is the date of approval or denial for the claim. This date may or may not be the same as the payment effective date from the remittance advice (STC08). In the 835, the payment effective date is BPR16.
- Some payers are able to provide the final claim adjudicated date prior to the remittance being issued.
- This is the payment effective date from the remittance advice. In the 835, this is the value in BPR16.
- This could include a non-payment remittance advice date if available from the Information Source's system.
- This is the unique identification number assigned to the payment in the remittance advice for tracking purposes. In the 835, this is the value from TRN02.
- This could include a non-payment remittance advice Trace Number (835 or paper) if available from the Information Source's system.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject Codes may be used for status related to pharmacy claims. When these codes are used, STC10-04 must have the value 'RX'.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject Codes may be used for status related to pharmacy claims. When these codes are used, STC11-04 must have the value 'RX'.
REF*1K - PAYER CLAIM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF*BLT - INSTITUTIONAL BILL TYPE IDENTIFICATION
At least one of REF02 or REF03 is required.
- Concatenate the 837I CLM05-01 (Facility Type Code) and CLM05-03 (Claim Frequency Code) values.
Code Source 236: Uniform Billing Claim Form Bill Type
Code Source 235: Claim Frequency Type Code - Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF*X1 - PROVIDER'S ASSIGNED CLAIM IDENTIFIER
At least one of REF02 or REF03 is required.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- For example, this is the value from CLM01 of an 837.
- The maximum number of characters to be supported for this qualifier is 35. Characters beyond the maximum are not required to be stored or returned by the receiving system.
REF*XZ - PHARMACY PRESCRIPTION NUMBER
At least one of REF02 or REF03 is required.
REF*VV - VOUCHER IDENTIFIER
At least one of REF02 or REF03 is required.
REF*D9 - CLAIM IDENTIFIER FOR TRANSMISSION INTERMEDIARIES
At least one of REF02 or REF03 is required.
REF*Y4 - PROPERTY & CASUALTY CLAIM NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
- For 837 Institutional claims, it is the statement period in Loop-ID 2300 (DTP01=434). For 837 Professional claims this information is derived from the earliest service level dates in Loop-ID 2400 (DTP01=472) to the latest service level date. For 837 Dental claims it is the service date at the claim level in Loop-ID 2300 (DTP01=472) or when not reported at Loop-ID 2300, it is derived from the earliest service level date in Loop-ID 2400 (DTP01=472) to the latest service level date.
- When reporting a claim level date, use the date from the Information Source's system for claim matches, otherwise return the date from the 276 status request.
DTP*050 - CLAIM RECEIVED DATE
PWK*V4 - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATION
- P0506
If either PWK05 or PWK06 is present, then the other is required. - P1011
If either PWK10 or PWK11 is present, then the other is required.
- The PWK segment is syntactically required in order to use the Transfer to Entity data in Loop ID 2210D.
- This is not for COB reporting or when a service is transferred internally within the payer's system(s).
PER*IC - TRANSFER TO ENTITY CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
N1 - TRANSFER TO ENTITY NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N3 - TRANSFER TO ENTITY ADDRESS
N4 - TRANSFER TO ENTITY CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
SVC - SERVICE LINE INFORMATION
- For Institutional claims, when both an NUBC revenue code and a HCPCS or HIPPS code are reported, the HCPCS or HIPPS code is reported in SVC01-02 and the revenue code is reported in SVC04. When only a revenue code is used, it is reported in SVC01-02.
- When a service specific claim status request is received, the claim status response may include additional service lines applicable to the claim.
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- This is the line item total on the current claim service status.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
STC - SERVICE LINE STATUS INFORMATION
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- All Category Codes except 'Request for Additional Information' (R Category Codes) are allowable at this level.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject/Payment Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject/Payment Codes may be used for status related to pharmacy claims. When these codes are used, STC01-04 must have the value 'RX'.
- This is the date of approval or denial for the service. This date may or may not be the same as the payment effective date from the remittance advice (STC08). In the 835, the payment effective date is BPR16.
- Some payers are able to provide the final service adjudicated date prior to the remittance being issued.
- This could include a non-payment remittance advice date if available from the Information Source's system.
- This is the payment effective date from the remittance advice. In the 835, this is the value in BPR16.
- This is the unique identification number assigned to the payment in the remittance advice for tracking purposes. In the 835, this is the value from TRN02.
- This could include a non-payment remittance advice Trace Number (835 or paper) if available from the Information Source's system.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject/Payment Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject/Payment Codes may be used for status related to pharmacy claims. When these codes are used, STC10-04 must have the value 'RX'.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject/Payment Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject/Payment Codes may be used for status related to pharmacy claims. When these codes are used, STC11-04 must have the value 'RX'.
REF*6R - LINE ITEM CONTROL NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
TOO - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
PWK*V4 - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATION
- P0506
If either PWK05 or PWK06 is present, then the other is required. - P1011
If either PWK10 or PWK11 is present, then the other is required.
AND
The entity in this loop is different or not present at the claim level (Loop ID-2210D). If not required by this implementation guide, do not send.
- The PWK segment is syntactically required in order to use the Transfer To Entity data in Loop ID 2225D.
- This is not for COB reporting or when a service is transferred internally within the payer's system(s).
PER*IC - TRANSFER TO ENTITY CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
N1 - TRANSFER TO ENTITY NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N3 - TRANSFER TO ENTITY ADDRESS
N4 - TRANSFER TO ENTITY CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
HL - DEPENDENT LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*QC - DEPENDENT NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
TRN*2 - CLAIM STATUS TRACE NUMBER
STC - CLAIM LEVEL STATUS INFORMATION
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- All Category Codes except 'Request for Additional Information' (R Category Codes) are allowable at this level.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject/Payment Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject Codes may be used for status related to pharmacy claims. When these codes are used, STC01-04 must have the value 'RX'.
- The total claim charge may change from the submitted claim total charge based on claims processing instructions, i.e. claim splitting. Some payers may not store the original submitted charge. Some HMO encounters supply zero as the amount of original charges.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- Zero is an acceptable amount when no payment is being made.
- Some payers are able to provide the adjudicated payment amount prior to the remittance being issued.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- This is the date of approval or denial for the claim. This date may or may not be the same as the payment effective date from the remittance advice (STC08). In the 835, the payment effective date is BPR16.
- Some payers are able to provide the final claim adjudicated date prior to the remittance being issued.
- This is the payment effective date from the remittance advice. In the 835, this is the value in BPR16.
- This could include a non-payment remittance advice date if available from the Information Source's system.
- This is the unique identification number assigned to the payment in the remittance advice for tracking purposes. In the 835, this is the value from TRN02.
- This could include a non-payment remittance advice Trace Number (835 or paper) if available from the Information Source's system.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject/Payment Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject Codes may be used for status related to pharmacy claims. When these codes are used, STC10-04 must have the value 'RX'.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The National Council for Prescription Drug Programs Reject Codes may be used for status related to pharmacy claims. When these codes are used, STC11-04 must have the value 'RX'.
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject Code (Code Source 530).
REF*1K - PAYER CLAIM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF*BLT - INSTITUTIONAL BILL TYPE IDENTIFICATION
At least one of REF02 or REF03 is required.
- Concatenate the 837I CLM05-01 (Facility Type Code) and CLM05-03 (Claim Frequency Code) values.
Code Source 236: Uniform Billing Claim Form Bill Type
Code Source 235: Claim Frequency Type Code - Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF*X1 - PROVIDER'S ASSIGNED CLAIM IDENTIFIER
At least one of REF02 or REF03 is required.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- For example, this is the value from CLM01 of an 837.
- The maximum number of characters to be supported for this qualifier is 35. Characters beyond the maximum are not required to be stored or returned by the receiving system.
REF*XZ - PHARMACY PRESCRIPTION NUMBER
At least one of REF02 or REF03 is required.
REF*VV - VOUCHER IDENTIFIER
At least one of REF02 or REF03 is required.
REF*D9 - CLAIM IDENTIFIER FOR TRANSMISSION INTERMEDIARIES
At least one of REF02 or REF03 is required.
REF*Y4 - PROPERTY & CASUALTY CLAIM NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
- For 837 Institutional claims, it is the statement period in Loop-ID 2300 (DTP01=434). For 837 Professional claims this information is derived from the earliest service level dates in Loop-ID 2400 (DTP01=472) to the latest service level date. For 837 Dental claims it is the service date at the claim level in Loop-ID 2300 (DTP01=472) or when not reported at Loop-ID 2300, it is derived from the earliest service level date in Loop-ID 2400 (DTP01=472) to the latest service level date.
- When reporting a claim level date, use the date from the Information Source's system for claim matches, otherwise return the date from the 276 status request.
DTP*050 - CLAIM RECEIVED DATE
PWK*V4 - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATION
- P0506
If either PWK05 or PWK06 is present, then the other is required. - P1011
If either PWK10 or PWK11 is present, then the other is required.
- The PWK segment is syntactically required in order to use the Transfer to Entity data in Loop ID 2210E.
- This is not for COB reporting or when a service is transferred internally within the payer's system(s).
PER*IC - TRANSFER TO ENTITY CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
N1 - TRANSFER TO ENTITY INFORMATION
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N3 - TRANSFER TO ENTITY ADDRESS
N4 - TRANSFER TO ENTITY CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
SVC - SERVICE LINE INFORMATION
- For Institutional claims, when both an NUBC revenue code and a HCPCS or HIPPS code are reported, the HCPCS or HIPPS code is reported in SVC01-02 and the revenue code is reported in SVC04. When only a revenue code is used, it is reported in SVC01-02.
- When a service specific claim status request is received, the claim status response may include additional service lines applicable to the claim.
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- This is the line item total on the current claim service status.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
STC - SERVICE LINE STATUS INFORMATION
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- All Category Codes except 'Request for Additional Information' (R Category Codes) are allowable at this level.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject/Payment Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject/Payment Codes may be used for status related to pharmacy claims. When these codes are used, STC01-04 must have the value 'RX'.
- This is the date of approval or denial for the service. This date may or may not be the same as the payment effective date from the remittance advice (STC08). In the 835, the payment effective date is BPR16.
- Some payers are able to provide the final service adjudicated date prior to the remittance being issued.
- This could include a non-payment remittance advice date if available from the Information Source's system.
- This is the payment effective date from the remittance advice. In the 835, this is the value in BPR16.
- This is the unique identification number assigned to the payment in the remittance advice for tracking purposes. In the 835, this is the value from TRN02.
- This could include a non-payment remittance advice Trace Number (835 or paper) if available from the Information Source's system.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject/Payment Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject/Payment Codes may be used for status related to pharmacy claims. When these codes are used, STC10-04 must have the value 'RX'.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- The Status Code is either a Health Care Claim Status Code (Code Source 508) or a National Council for Prescription Drug Programs Reject/Payment Code (Code Source 530).
- The National Council for Prescription Drug Programs Reject/Payment Codes may be used for status related to pharmacy claims. When these codes are used, STC11-04 must have the value 'RX'.
REF*6R - LINE ITEM CONTROL NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
TOO - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
PWK*V4 - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATION
- P0506
If either PWK05 or PWK06 is present, then the other is required. - P1011
If either PWK10 or PWK11 is present, then the other is required.
AND
The entity in this loop is different or not present at the claim level (Loop ID-2210E). If not required by this implementation guide, do not send.
- The PWK segment is syntactically required in order to use the Transfer To Entity data in Loop ID 2225E.
- This is not for COB reporting or when a service is transferred internally within the payer's system(s).
PER*IC - TRANSFER TO ENTITY CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
N1 - TRANSFER TO ENTITY NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N3 - TRANSFER TO ENTITY ADDRESS
N4 - TRANSFER TO ENTITY CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
SE - TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 276/277 Health Care Claim Status Request and Response (008020X329)SEPTEMBER 2021 Copyright © 2008-21, X12 Incorporated, Format © 2008-21 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner. All rights reserved. Abstract The Health Care Claim Status Request and Response Implementation Guide describes the use of the X12 Health Care Claim Status Request (276) and the X12 Health Care Information Status Request (277) transaction sets for the following business usage:
|
PrefaceX12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3), also known as implementation guides, define the explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data consistently with multiple trading partners. As X12 does not define transport requirements, trading partners define their specific transport requirements separately. |
1.1 Implementation Purpose and ScopeFor the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed to facilitate consistent implementation by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical. The purpose of this implementation guide is to provide standardized data requirements and content for all users of the X12 Health Care Claim Status Request (276) and the X12 Health Care Information Status Notification (277). This implementation guide focuses on the use of the 276 to request the status of a health care claim(s) and the 277 to respond with the information regarding the specified claim(s). This implementation guide provides detailed explanations of the transaction sets by defining uniform data content, identifying valid code tables, and specifying values applicable for the business focus of the 276 Health Care Claim Status Request and the 277 Health Care Claim Status Response. The intention of the developers of the 276 and 277 is represented in the guide. Entities using the 276 to request health care claim status include, but are not limited to, hospitals, nursing homes, laboratories, physicians, dentists, allied professional groups, employers, and supplemental (i.e., other than primary payer) health care claims adjudication processors. Organizations sending the 277 response include payers, who may be insurance companies; third party administrators; service corporations; state and federal agencies and their contractors; and any other entity that processes health care claims. Other business partners affiliated with the 276 and/or the 277 include billing services; consulting services; vendors of systems; software and EDI translators; and EDI network intermediaries such as Automated Clearing Houses (ACHs), Value-Added Networks (VANs), and telecommunications services. |
1.2 Version InformationThis implementation guide is based on the October 2020 X12 standards, referred to as Version 8, Release 2 (008020). The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 008020X329. The two-character Functional Identifier Code for the transaction set included in this implementation guide:
The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. For more information, see the descriptions of GS01 and GS08 in Appendix C EDI Control Directory. |
1.3.1 Batch and Real-Time UsageThere are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and real-time. Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery or transmits the response transaction back to the sender of the original transaction. The sender of the original transmission reconnects at a later time and picks up the response transaction. Note: The sender of the original transmission may not always be the entity that picks up the response transaction at a later time (e.g. Provider submitting through a clearinghouse.) Real-Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers. This implementation guide was based on requirements for batch and real-time modes. Willing trading partners may use batch or real-time mode. |
1.3.2 Other Usage LimitationsThere are other usage limitations. |
1.3.2.1 Real-Time and Batch TransmissionsThe Claim Status Request and Response transaction may be sent in batch or real-time. If trading partners are going to engage in both transmission options, it is recommended they establish a method for identifying the difference. Real-Time Limitations
Batch Limitations
|
1.3.2.2 Claim Status Category Codes
|
1.3.2.3 277 Business FunctionsAdditional 277 business functions that are not in direct response to a Claim Status Request (276) are not supported in this implementation. See Section 1.4.6 - 277 Transaction Uses, for additional information on the varied 277 business functions. |
1.4 Business UsageThe X12 Health Care Claim Status Request and Response (276/277) implementation guide addresses the paired usage of the 276 as a request for claim status and the 277 as a response to that request. The 276 is used to transmit request(s) to obtain the status of specific health care claim(s) within a payer's adjudication process. It can also be used to request status information on a previously submitted predetermination. The payer uses the 277 to transmit the current system status of those requested claims or predeterminations. Claim history parameters may vary by payers and systems. Status information can be requested and responded to at the claim and/or service level. The 276 provides information that is necessary for the payer to identify the specific claim(s) in question. Some primary or unique identifying element(s) may be supplied to obtain an exact match for that request. However, when the 276 does not uniquely identify the claim within the payer's system, the response may include multiple claims that meet the parameters supplied by the requester. Figure 1.1 - Information Flow for Claim Status Request/Response, illustrates the flow of information for the 276 Health Care Claim Status Request and the 277 Health Care Claim Status Response. Figure 1.1 - Information Flow for Claim Status Request/Response |
1.4.1 Health Care Transaction FlowEach X12 implementation guide explains how to use X12 transaction sets to meet a single defined business purpose. The diagrams found at https://www.x12.org/flow depict the business functions supported by the X12 health care implementation guides. |
1.4.2 Transaction ParticipantsThe hierarchical level structure is used to identify and relate the participants involved in the transaction. The relationships between the hierarchical levels are described by the hierarchical level code data elements, also known as HL01 and HL02. The data element, HL03, identifies the participants within the transaction. The hierarchical structure and participants are the same for both the 276 and 277. The participants described are as follows: When HL03 = 20, the hierarchical level contains the Information Source. This entity is the decision maker in the business transaction. For this business use, this entity is the payer who has the current status information for the specified claims. When HL03 = 21, the hierarchical level contains the Information Receiver. This entity expects the response from the Information Source. For this business use, this entity can be a provider, a provider group, a claims clearinghouse, a service bureau, an agency, an employer, a Factoring Agent, etc. This entity will be identified via their electronic ID as the sender of the 276 Request and receiver of the 277 Response. When HL03 = 19, the hierarchical level contains the Provider of Service. This entity delivered the health care service. Provider of Service is generic in that this could be the entity that originally submitted the claim (Billing Provider) or may be the entity that provided or participated in some aspect of the health care (Rendering Provider). When HL03 = 22, the hierarchical level contains the Insured or Subscriber information. This entity is the contract holder of the health care benefits. This entity may or may not be the recipient of the health care service rendered. See Section 1.4.2.1 - Defining the "Patient" Participant, for more information on this entity. When HL03 = 23, the hierarchical level contains the Dependent information. This entity is eligible for health care benefits due to their relationship to the subscriber. When this HL is reported, this entity is the recipient of the health care service rendered. See Section 1.4.2.1 - Defining the "Patient" Participant, for more information on this entity. The Information Receiver and the Service Provider hierarchical levels have a unique relationship. Information Receiver refers to the entity that processes the detailed information contained within the transaction set. In some cases, the Information Receiver is an entity acting on behalf of the Service Provider. When this occurs, the entity is described when HL03 = 21, and the Provider of Service is described when HL03 = 19. In other instances, the Information Receiver is also the Service Provider. When this occurs, the same entity is described at two hierarchical levels - when HL03 = 21 and when HL03 = 19. The coding examples are presented sequentially as found within an actual transaction set. However, for reading ease each segment begins on a new line. The following example demonstrates the coding of the segments and data elements within the Information Source hierarchical level: HL*1**20*1~ The following is a coding example of the Information Receiver hierarchical level: HL*2*1*21*1~ The following is a coding example of the Service Provider hierarchical level: HL*3*2*19*1~ The following is a coding example of the Subscriber Hierarchical level: HL*4*3*22*1~ The following is a coding example of the Dependent Hierarchical level: HL*5*4*23~ |
1.4.2.1 Defining the "Patient" ParticipantSubscriber Loop 2000D and Dependent Loop 2000E identify the patient for whom a claim status inquiry is being generated. When reporting status at the patient level (see Section 1.4.4.2 - Status Response Levels), Loop 2000D is always used. Loop 2000E is used only when necessary to identify a patient who is a dependent that does not have a unique identification number.
|
1.4.3 Claim and Service InformationUnlike the Transaction Participants, specific claim and service details are not given a hierarchical level. Claim and Service details are positioned in the same hierarchical level that describes its owner-participant, either the Subscriber or the Dependent. The claim(s) details are said to "float". That means the claim(s) details are placed at the Subscriber hierarchical level (2200D) when the patient is the subscriber or a uniquely identified dependent. The claim(s) details are placed at the Dependent hierarchical level (2200E) when the patient is the dependent of the subscriber and not uniquely identified. The specific claim(s) in question are described in Loop 2200 in both the 276 and 277 transactions, while the service information follows the claim data in Loop 2210 of the 276 and Loop 2220 of the 277. |
1.4.3.1 The ClaimThe 276 and 277 Loop 2200 may contain different segments, with the exception of the TRN Segment (Claim Status Trace Number). However, the intent of the loop is similar in both transactions. The provider and payer may identify the claim within their respective system using different data. As a result, the segments used for the request (276) may differ from the segments returned in the response (277). When claim status is requested, the provider supplies data that helps the payer locate the claim(s). The provider may send general claim data such as dates of service, claim amount or bill type in an effort to receive status on multiple claims with those same attributes. When the provider includes claim specific identifiers, such as the Provider's Assigned Claim Identifier or the Payer Claim Control Number, they are indicating to the payer that the search and response be narrowed to very specific claims. Use of the Provider's Assigned Claim Identifier in the payer's search and matching criteria may be helpful in narrowing the response to specific claims for which the provider has requested status. See Section 1.4.8 - Payer Claim Control Number Search and Response for specific search and response requirements when the Payer Claim Control Number is submitted in the 276 request. Reassociation of the response to the original request is a necessity of the 276/277 paired transaction. The reassociation is accomplished with a unique trace or reference number identified in the TRN Segment (Claim Status Trace Number), Data Element (TRN02). This number is determined by the originator (Information Receiver) of the 276 and must be returned in the 277 by the sender (Information Source). The 277 response TRN02 must contain the same value that was submitted in the 276 request. The only exception for not returning the 2200D or 2200E TRN segment in the 277 is when a rejection status is reported at the Information Receiver Level. In this instance, the lower level (child) HL is not used. See Section 1.4.4.2 - Status Response Levels, for details on an Information Receiver Level rejection. |
1.4.3.2 The ServiceThe service information follows the claim data in Loop 2210 (Service Line Information) of the 276 and Loop 2220 (Service Line Information) of the 277. Some payers' adjudication systems support service line information. When the requester is inquiring on the status of a specific service, Loop 2210 must be populated in the 276. When the payer is reporting the status of a specific service, Loop 2220 must be populated in the 277. Similar to the claim level, the provider may send general service data such as dates of service, amount and procedure codes in an effort to receive status on multiple services and claims with those same attributes. When the provider includes a Line Item Control Number, they are indicating to the payer that the search and response be narrowed to a very specific service line on a previously submitted claim. Use of the Line Item Control Number in the payer's service level search and matching criteria may be helpful in narrowing the response to the specific services for which the provider has requested status. For Service line status requests and responses, the SVC segment (Service Line Information) is used to report the actual service (procedure) data. The SVC Segment is returned by the payer indicating the adjudicated procedure code. Due to the payer's adjudication processes and policies, service line data may be changed as a result of bundling or unbundling. In this case, the service line(s) returned in the 277 may be different than those submitted in the 276. Procedure code bundling or unbundling occurs when a payer believes the actual services performed and reported for claim payment can be represented by a different group of procedure codes. Bundling occurs when two or more submitted procedures are processed using one procedure code. Unbundling occurs when one submitted procedure code is processed and reported back as two or more procedure codes. |
1.4.3.3 Claim and Service Loop PlacementThe following reflects the transaction participant structure, along with the claim and service loops placement for the identified patient. See Section 1.4.2.1 - Defining the "Patient" Participant, for the definition of the patient. Claim and Service loop placement when the patient is the subscriber or a dependent with a unique identification number. 276 Request 277 Response (multiple claim response) Claim and Service loop placement when the patient is a dependent of the subscriber. The dependent has the same identification number as the subscriber. 276 Request (multiple service requests) 277 Response (multiple service responses) Claim and Service loop placement for multiple patient requests (batch mode) where one patient is the subscriber (A) and one or more other patients (A.1, A.2) are dependents of that subscriber (A). The dependent(s) has the same identification number as the subscriber. 276 Request 277 Response |
1.4.4 277 Status Information (STC) Segment UsageThe primary vehicle for the claim status information in the 277 Transaction is the Status Information (STC) Segment. The level of information returned in the STC Segment may vary from payer to payer. Payers are urged to provide the greatest level of response detail to the Information Receiver so that the data exchange is beneficial to both entities. Payers who meet the minimum required basics, defined in Section 1.4.4.1 - STC Composite and Code Use Rules, may not satisfy the receiver's need for complete and detailed status which could result in the generation of subsequent inquiries to the payer. The STC segment contains three iterations of the Health Care Claim Status composite data element (C043) within STC01, STC10 and STC11. Multiple STC segments may be sent when needed to fully explain the claim status. The Health Care Claim Status composite (C043) consists of four elements: The first element in the C043 composite (C043-01) is the Health Care Claim Status Category Code (Code Source 507). The Category Code indicates the payer's current system status of the claim. This implementation guide allows the use of all Category Codes in the list, except the 'Request for Additional Information Codes' (R). The 'Request' codes apply only to the 277 Request for Additional Information Implementation Guide (see Section 1.4.6 - 277 Transaction Uses). The second element in the C043 composite (C043-02) is either the Health Care Claim Status Code (Code Source 508) or the National Council for Prescription Drug Programs Reject/Payment Codes (Code Source 530). These codes provide more specific information about the claim or line item. The third element in the C043 composite (C043-03) is the Entity Identifier Code (X12 data element 98). The Entity Identifier code is used to clarify the entity when referred to in the status message (C043-02). The code list identifies an organizational entity, a physical location, property, or an individual. A list of appropriate code values for data element 98 appears within the STC segments in Section 2.6. The fourth element in the C043 composite (C043-04) is the Code List Qualifier Code (X12 data element 1270). This element is Situational and only used when identifying the second element of the composite (C043-02) as a National Council for Prescription Drug Programs Reject/Payment Code. When this element is used, it will contain code value 'RX' - National Council for Prescription Drug Programs Reject/Payment Codes. A committee of healthcare industry representatives from payer, provider and vendor organizations maintain the Health Care Claim Status Category Codes and Health Care Claim Status Codes (Code Sources 507 and 508). They are updated after each X12 Standing meeting. Version specific code additions or deactivations are noted on the code lists. The primary distribution source is the X12 website (https://x12.org/codes). This website includes external code lists maintained by X12 and external code lists maintained by others and distributed by WPC on behalf of the maintainer. It provides a maintenance request facility that allows interested parties to request new codes, request changes to existing codes, or view the status of pending requests. The National Council for Prescription Drug Programs (NCPDP) Reject/Payment Codes are maintained by the National Council for Prescription Drug Programs. For information on the NCPDP Reject/Payment Codes (Code Source 530) refer to Appendix A, External Code Sources. |
1.4.4.1 STC Composite and Code Use RulesThe following rules apply to use of the composites and codes within the STC segment:
|
1.4.4.2 Status Response LevelsThe STC segment is used in the 277 at various participant levels and within the claim and service loops for the patient level (subscriber or dependent). When the 277 transaction is sent, a status response is not required at all levels within the transaction. In most instances, the Information Source must respond with status at the appropriate patient level (Subscriber or Dependent loop) of the claim, and when applicable the service level. Responses at these patient levels meet the intended business purpose of this paired transaction. The following describes use of the various status levels. Loop 2200B - Information Receiver Only the 'D0' Category Code and 'E' Category Code types are allowed at the Information Receiver status level. Loop 2200D or 2200E - The Claim Level This implementation guide allows the use of all Category Codes in the list, except the 'Request for Additional Information Codes' (R Category Codes) at the claim level. Loop 2220D or 2220E - The Service Level This implementation guide allows the use of all Category Codes in the list, except the 'Request for Additional Information Codes' (R Category Codes) at the service level. When service lines within a claim have various statuses (example both pending and finalized), a single Category Code grouping (example P or F category codes) must be reflected at the claim level and the specific statuses must be reported at the service level (2220D or 2220E). |
1.4.4.3 Status Messaging for Subscriber Direct Paid Claims/ServicesThe 276/277 Claim Status response will return payment information in situations where providers or subscribers are paid directly and this section outlines what will be returned when that occurs. These situations may occur when the provider of service does not have a contract with the payer. For consistency across the industry, the information returned in the 277 status in the STC Segment in Loops 2200D/E (Claim Level Status Information) must be reported as noted below. Loops 2220D/E (Service Line Level status), when reported, must be consistent with the Claim Level response. STC01-01 – Health Care Claim Status Category Code = F4: Finalized/Adjudication Complete — No payment forthcoming — The claim/encounter has been adjudicated and no further payment is forthcoming. STC01-02 – Health Care Claim Status Code = 6: Balance due from the subscriber. STC05/SVC03 – Payment Amount: Report as a value of zero (0). STC06 – Adjudication Finalized Date: Report the date the remittance cycle is complete. |
1.4.5 Payer's System Status LocationsIn response to a 276 request, the 277 can support responding with status for claims in the payer system locations identified in sections 1.4.5.1 through 1.4.5.3 (Pre-Adjudication, Pended and Finalized). However, a payer's response capability for claim status in those locations will vary from payer to payer, as well as their determination of when a claim is in a pended versus finalized status. |
1.4.5.1 Pre-AdjudicationPayers may pre-process claims to determine whether or not to introduce them to their adjudication system. This process is performed so that incorrectly formatted claims or those that are missing information can be returned to the provider for correction. Returned claims may not have a claim number assigned by the payer. Status for claims in this location generally use the 'Acknowledgments' (A) Category Codes. |
1.4.5.2 PendedPayers may perform various functions, such as validation editing, medical reviews, contractual requirements, request additional information, etc. within their adjudication system that may cause claims to be placed in a 'pended' or 'suspended' status. Payers usually assign a claim number to a pended claim. Claims generally remain in a 'pending' state until the payer resolves or completes validation editing, medical reviews, etc. and the claims are finalized. Status for claims in this location generally use the 'Pending' (P) Category Codes. |
1.4.5.3 FinalizedClaims that complete the adjudication process and/or remittance cycle are referred to as 'finalized' claims. The adjudication determination on finalized claims has concluded. Claims in a finalized status may include rejected, denied, approved for payment and paid. Status for claims in this location generally use the 'Finalized' (F) Category Codes. |
1.4.6 277 Transaction UsesThe Health Care Information Status Notification (277) transaction set has multiple implementation conventions to meet various business needs of the health care industry. The transaction set can be used to provide healthcare claim information in the following business scenarios:
Figure 1.2 - General X12 Health Care Claim Information Flow illustrates the flow of information related to several usages of the 277. The multiple uses of the 277 claim status are differentiated by values in the ST and BHT Segments of Table 1 data. Element BHT06, in addition to the ST03 and GS08 values, is used to distinguish between these varied business functions. The various 277 - BHT06 code values are:
Figure 1.2 - General X12 Health Care Claim Information Flow |
1.4.7 PredeterminationsWhen claim status is requested for predeterminations, a DTP segment denoting the date of service should not be included. The 276 transaction can be identified as containing requests for status on either dental or medical predeterminations via the situational data element BHT06 with qualifiers P5 (Predetermination – Medical) and P6 (Predetermination – Dental). BHT06 would not be used when requesting status for claims where the service has already been rendered. |
1.4.8 Payer Claim Control Number Search and ResponsePayers may use whatever Trading Partner, Provider and Member/Patient data, along with the Payer Claim Control Number, that is submitted in the 276 Request in order to perform their claim validation processes against the data within their system. Once validation has been confirmed, when the provider submits the Payer Claim Control Number, REF Segment (Payer Claim Control Number) in either Loop ID 2200D or 2200E (Claim Status Tracking Number) of the 276 Request, the payer must attempt a match using the claim number requested and return a response for that specific claim number. Required Responses When the claim is not found, the payer must return a response for the requested claim number in the 277 Response, either in Loop ID 2200D or 2200E (Claim Status Trace Number) REF Segment (Payer Claim Control Number) with the following status response in Loop ID 2200D or 2200E (Claim Status Trace Number), STC Segment (Claim Level Status Information), Data Element STC01 (Health Care Claim Status). STC01 Additional status codes may be reported in STC10 and STC11 (Health Care Claim Status) to identify other data related to the submitted Payer Claim Control Number that may have caused the claim not to be found within the payer's system. For example, if the payer uses the patient's last name as part of their matching or validation criteria and it did not match, status code 504 could also be used (504 - Entity's Last Name. Note: This code requires use of an Entity Code.). Secondary Search and Response If the specific Payer Claim Control Number requested is not found, payers may attempt a secondary claim search utilizing other data elements submitted on the 276 request, in order to provide status to the provider on claims with similar attributes to the other submitted data. When a secondary search is performed and status is being returned for additional Payer Claim Control Numbers, the first occurrence of Loop ID 2200D or 2200E (Claim Status Trace Number) must contain the required response for the Payer Claim Control Number that was submitted, but not found. Subsequent 2200D or 2200E (Claim Status Trace Number) Loops would then contain status for other claims found in the payer's system that had the same or similar attributes to the data submitted in the 276. |
1.5 Business TerminologyTo ensure consistent use of terms, definitions, and acronyms across X12 products, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12's work. The terms and definitions defined in the Wordbook are used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org. |
1.6 Transaction AcknowledgmentsThe purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected. The X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems. |
1.7 Related TransactionsThere are one or more transactions related to the transactions described in this implementation guide. |
1.7.1 The Claim (837)Submitting a claim, whether by using the 837 or another format, is the first step in the claim status request/response process. Certain data elements (e.g., the Provider's Assigned Claim Identifier, type of bill, dates of service, insured identifier, service provider identifier, and payer's claim number when available) found on the claim help locate a claim within a payer's adjudication system. When the provider initiates a claim status request, as many of these data elements as possible should be forwarded to the payer. With the exception of the payer's claim number, the source of this information is the provider's billing system. |
1.7.2 The Remittance AdviceThe Remittance Advice, whether using an electronic transaction (835) or paper, provides the final adjudication details related to the payment or denial of a claim. The 277 Claim Status Response is not intended to provide the final claim adjudication details. Some remittance advice data is reflected in the 2200 STC to provide the link between the finalized claim and the remittance advice on which it was reported. |
1.8 Trading Partner AgreementsTrading partner agreements are used to establish and document the relationship between trading partners. A trading partner agreement must not override the specifications in this implementation guide if a transmission is reported in GS08 to be a product of this implementation guide. |
1.9 Transaction ComplianceThere are three types of compliance that may be relevant to a transmitted transaction. Compliance with implementation guide requirements Compliance with state and federal regulation Compliance with trading partner contractual agreements |
1.9.1 Transaction Compliance with Implementation Guide RequirementsA transaction complies with X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable X12 standards and the implementation guide (also known as a TR3) itself. Should additional clarification of an X12 implementation guide requirement be desired, two options are available.
X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that are not TR3-compliant based on its own business process. A receiver may specify its business rules in a trading partner agreement or companion document. As stated in §1.8, these documents do not override TR3 requirements, nor change how transaction compliance with this TR3 is determined. |
1.9.2 Transaction Compliance with State and Federal RegulationsThis implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a state or federal standard. Should this implementation guide be adopted as a standard, the adopting authority will establish compliance dates for its use by impacted entities. X12 is not the authority for determining compliance with regulatory requirements that might further constrain implementation guide requirements. Questions of compliance for regulatory requirements should be directed to the governing authority. X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with applicable regulatory requirements as specified by the applicable regulation(s) or governing authority. |
1.9.3 Transaction Compliance with Contractual RequirementsX12 is not the authority for determining compliance with contractual requirements that might further constrain implementation guide requirements. Questions of compliance for contractual requirements should be directed to the contracting entity. X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with contractual requirements as specified by the applicable contract or contracting entity. |
1.10 Data OverviewThis section introduces the structures of the 276 and 277. Familiarity with X12 nomenclature, segments, data elements, hierarchical levels, and looping structure is recommended. For a review, see Appendix B, X12 Control and Guidance and Appendix C, EDI Control Directory. |
1.10.1 Overall Data ArchitectureTwo formats, or views, are used to present the transaction set: the implementation view and the standard view. The intent of the implementation view is to clarify the purpose and use of the segments by restricting the view to display only those segments used with their assigned health care names. The implementation views for both the 276 and 277 are presented in the Implementation Sections 2.3.1 and 2.5.1, respectively. The standard views for both the 276 and 277 display all segments available within the transaction sets with their assigned X12 names. These views are presented in the X12 Standard Sections 2.3.2 and 2.5.2, respectively. The 276 and 277 transaction sets are similar in structure but are not duplicates. Both transaction sets are divided into two levels, or tables, Table 1 and Table 2. Table 1 Table 2 The following are HL segment coding examples and the data element significance within the HL segments:
|
2.1 Presentation ExamplesThe X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable. This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only. The transaction set presentation is comprised of two main sections with subsections within the main sections: Transaction Set Listing There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself. This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail. This section is included as a reference. Segment Detail There are three sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and X12 standard detail. This section is included as a reference. This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation. This section specifies the implementation details of each data element. These illustrations (Figures 2.1 through 2.5) are examples and are not extracted from the Section 2 detail in this implementation guide. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows. Figure 2.1 - Transaction Set Key - Implementation Figure 2.2 - Transaction Set Key - Standard Figure 2.3 - Segment Key - Implementation Figure 2.4 - Segment Key - Diagram Figure 2.5 - Segment Key - Element Summary |
2.2.1 Industry UsageIndustry Usage describes when loops, segments, and elements are to be sent when complying with this implementation guide. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational).
|
2.2.1.1 Determining Transaction Compliance with Industry Usage RequirementsA transmitted transaction complies with the governing implementation guide when it satisfies the requirements as defined within the implementation guide. Specifically, the presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this implementation guide according to the following table.
|
2.2.2 LoopsLoop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.
|
3. ExamplesBusiness scenario examples for use of this transaction can be found on the X12 Examples website at http://examples.x12.org. The X12 Examples website provides convenient access to examples of X12 transaction transmissions, including the data stream and a description of the associated scenario. |
| Â | ||||
Appendix A. External Code SourcesPrior to this publication, X12 TR3s contained a subset of the overall Code Source Directory, formerly known as Appendix A of X12.3. External code lists are not part of the X12 standard and are provided for information purposes only. The full listing is available in Glass, X12's On-Line viewer. Read more about Glass here: https://glasshelp.x12.org/. Where an external code source is referenced in this publication, the implementer is required to use only the codes from that list. Codes must be reported as listed in the code source (e.g. with leading zeroes). Implementers must follow the instructions for code use that are supplied by the code set owner. | ||||
| Â | ||||
B.1.1 X12 Referenced and Related StandardsThis technical report is based on the X12 EDI standard which comprises a series of interdependent publications. Implementers are advised to consult these publications when using this technical report. The following standards are required to interpret, understand, and use this technical report:
The following guideline is useful to interpret, understand, and use this technical report:
The following reference model is useful to interpret, understand, and use this technical report:
All of the documents above are available online using links to X12's Online Viewer. | ||||
| Â | ||||
B.1.1.1 Transmission Control SchematicRefer to X12.5 - Interchange Control Structures, Section 3.5 - Order of Control Segments, and Chapter 5 Interchange Segment Specifications. Similar transaction sets, called "functional groups," can be sent together within a transmission. Each functional group is prefaced by a group start segment; and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure B.1 - Transmission Control Schematic, illustrates this interchange control. Figure B.1 - Transmission Control Schematic | ||||
| Â | ||||
B.1.1.2 Constraints applicable to the suite of TR3sRefer to X12.6 - Application Control Structure, Section 3.2.8 - Minimums/Maximums. Data element minimum and maximum lengths are set by the X12 standard. This implementation guide may further restrict minimum and maximum lengths within the bounds set by the standard. Such restrictions may occur implicitly by virtue of the allowed qualifier for the data element, or they may be stated explicitly in a note attached to the element or in the general limitations below. | ||||
| Â | ||||
B.1.1.2.1 Maximum Length of Data Element 127 Reference IdentificationThe current X12 standard allows a maximum length greater than 50 characters for data element 127. For implementations governed by this implementation guide, unless another value is specified in an attached note, the maximum length of each occurrence of this data element is constrained to 50 characters. | ||||
| Â | ||||
B.1.1.2.2 Maximum Length of Data Element 782 Monetary AmountFor implementations governed by this implementation guide, unless another value is specified for an instance of Data Element 782 within Section 2 (Transaction Set), each occurrence of Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note that the decimal point and leading sign, if sent, are not part of the character count. EXAMPLE
| ||||
| Â | ||||
B.1.1.3 DecimalWhile the X12 standard supports usage of exponential notation, this guide prohibits that usage. | ||||
Appendix D. Change SummaryThis Implementation Guide (008020X329) defines the X12 requirements for the Health Care Claim Status Request and Response. It is based on version/release/subrelease 008020 of the X12 standards. |