275 Transaction Set Listing
006020X314 Additional Information to Support a Health Care Claim or Encounter- Loop 1000A - PAYER NAMERequired1
- Loop 1000B - SUBMITTER INFORMATIONRequired1
- Loop 1000C - PROVIDER NAME INFORMATIONRequired1
- Loop 1100C - PROVIDER IDENTIFICATIONRequired1
- Loop 1000D - PATIENT NAMERequired1
- Loop 2000A - ASSIGNED NUMBERRequired>1
- Loop 2100A - SERVICE LINE SERVICE DATESituational1
- Loop 2100B - ADDITIONAL INFORMATION SUBMITTED DATERequired1
- Loop 2110B - ASSOCIATED OBJECT TYPE IDENTIFICATIONRequired1
ISA - INTERCHANGE CONTROL HEADER
- All positions within each of the data elements must be filled.
- 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.
- The ISA segment terminator defines the segment terminator used throughout the entire interchange.
- Spaces in the example interchanges are represented by "." for clarity.
- 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*PI - FUNCTIONAL GROUP HEADER
ST*275 - 275 TRANSACTION SET HEADER
BGN - BEGINNING SEGMENT
If BGN05 is present, then BGN04 is required.
- The originator of the transaction set assigns the unique reference number in BGN02 and the date of creation in BGN03.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
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.
NM1*41 - SUBMITTER INFORMATION
- 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.
NM1*1P - PROVIDER NAME INFORMATION
- 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.
- In the solicited 275 model, the information from the 2100C NM1 segment of the 277 must be returned in this segment.
- In the unsolicited 275 model, the billing provider information must be sent in this segment.
PRV*BI - PROVIDER TAXONOMY INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
REF - PROVIDER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
NX1*1P - PROVIDER IDENTIFICATION
N3 - PROVIDER ADDRESS
N4 - PROVIDER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 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
NM1*QC - PATIENT 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.
REF*X1 - PROVIDER'S ASSIGNED CLAIM IDENTIFIER
At least one of REF02 or REF03 is required.
- The maximum number of characters to be supported for this data element is "35". A provider may submit fewer characters depending upon their needs.
- 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*BLT - INSTITUTIONAL TYPE OF BILL
At least one of REF02 or REF03 is required.
- The value in REF02 corresponds to a concatenation of Facility Type Code (CLM05-01) and Claim Frequency Type Code (CLM05-03) from the ASC X12N 837 claim transaction or this is the value from REF02 in the 2200D loop of the 277.
- 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*EA - MEDICAL RECORD IDENTIFICATION NUMBER
At least one of REF02 or REF03 is required.
- This is the Medical Record Identification Number from the original claim.
- 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*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.
- This is the Property & Casualty Claim Number assigned by the payer for the claim event.
- If the Property and Casualty payer assigned Claim Number is submitted in the bill for service (e.g 837) or in the Request for Additional Information (277), then the number in this REF must be the number submitted in the bill or request for additional information.
DTP*472 - CLAIM SERVICE DATE
LX - ASSIGNED NUMBER
- The LX segment can be repeated to respond to multiple questions on an individual claim. The 275 transaction structure only allows the submitter to send one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim.
- Within the LX, LX01 is the sequence number of the LX Loop. It is required that the LX01 sequence number start at 1 and increment by 1.
TRN - PAYER CLAIM CONTROL TRACE NUMBER/PROVIDER ATTACHMENT CONTROL TRACE NUMBER
- Payer Claim Control Number is the value from the 277 TRN segment of the 2200D loop, when in response to a solicited request.
- For the unsolicited 275, if the attachment applies to entire 837, the Provider Attachment Control Number is the value from the 837 PWK06 of the 2300 loop. If the attachment applies to a specific service line, the Provider Attachment Control Number is the value from the 837 PWK06 for that service line in the 2400 loop. This is the main matching criteria and must be unique on a per attachment basis.
- The TRN02 value must be the same in each iteration of the 2000A loop when the value in TRN02 is the Payer claim control number.
- When the value in BGN01 is 11, this number will be the payer claim control number that is in TRN02 of the 2200D loop, in the 277. This value must be the same in each LX loop.
- When the value in BGN01 is 02, this number is the unique control number that the provider assigned for the attachment. It must match the number in PWK06 loop 2300 of the 837. This is the main matching criteria and must be unique on a per attachment basis. When using the Attachment Control Number the minimum length requirement is 2. For the unsolicited 275, payers and clearinghouses may ensure a match of the 275 attachment to the claim by concatenating other data in this transaction to the value in TRN02.
- The payer does not set the format for the Attachment Control Number. However, the payer may have some system constraints, e.g. maximum readable length, that the provider needs to take into account when formatting this Control Number.
- 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 - 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.
- This will be the LOINC® Code that defines the additional information that was requested.
- See Code Source 663: Logical Observation Identifier Names and Codes (LOINC®)
- 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 Code Source 663: Logical Observation Identifier Names and Codes (LOINC®)
- This will be the LOINC® Code that further specifies the request for 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.
- See Code Source 663: Logical Observation Identifier Names and Codes (LOINC®)
- This will be the LOINC® Code that further specifies the request for information.
REF*6R - SERVICE LINE ITEM IDENTIFICATION
At least one of REF02 or REF03 is required.
REF*3H - CASE REFERENCE IDENTIFIER
At least one of REF02 or REF03 is required.
REF*X9 - ATTACHMENT REQUEST TRACKING IDENTIFIER
At least one of REF02 or REF03 is required.
HI - HEALTH CARE INFORMATION CODES
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
SVC - SERVICE 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.
If a new rule names the Jurisdiction Specific Procedure and Supply Codes as an allowable code set under HIPAA,
OR
The Secretary grants an exception to use the code set as a pilot project as allowed under the law,
OR
For claims which are not covered under HIPAA.
The qualifier may only be used in transactions covered under HIPAA:
By parties registered in the pilot project and their trading partners,
OR
If a new rule names the Complementary, Alternative, or Holistic Procedure Codes as an allowable code set under HIPAA,
OR
For claims which are not covered under HIPAA.
DTP*472 - SERVICE LINE SERVICE DATE
DTP*368 - ADDITIONAL INFORMATION SUBMITTED DATE
CAT*AE - FORMAT AND VERSION IDENTIFIER
- C0302
If CAT03 is present, then CAT02 is required. - P0405
If either CAT04 or CAT05 is present, then the other is required. - C0605
If CAT06 is present, then CAT05 is required. - C0704
If CAT07 is present, then CAT04 is required.
OOI - ASSOCIATED OBJECT TYPE IDENTIFICATION
BDS - BINARY DATA SEGMENT
- It is recommended that the contents of the BDS not exceed 64 megabytes. When for example, a BDS must be split due to size limitations, the 2000A loop must be repeated.
- Please refer to the HL7 standard for an example of the attachment content. The BDS segment is used to hold the additional information. It allows for the use of the HL7 standard using the 275 transaction as the envelope.
- Senders must ensure that the count in BDS02 is equal to the byte count of the contents of the BDS03.
- It has been noted that line constraints, transfer protocols, zip programs or conversion processes may insert additional control characters such as line feeds, carriage returns or other specific characters into a transaction. If this occurs in BDS03, the sender's stated count in BDS02 may no longer be equal to the received contents of the data in BDS03 but in no case should it be less than the count indicated in BDS02.
SE - 275 TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 275 Additional Information to Support a Health Care Claim or Encounter (006020X314)SEPTEMBER 2014 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 Additional Information to Support a Health Care Claim or Encounter Implementation Guide describes the use of the ASC X12 Patient Information (275) transaction set for the following business usage:
|
PrefaceASC X12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3) define explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data with multiple trading partners in a consistent manner. Trading partners define their specific transport requirements separately. Neither ASC X12 standards nor TR3s define transport requirements. |
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 and need to be implemented consistently 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 to all users of the ASC X12 Patient Information (275) Transaction Set that focuses on the use of the 275 to send additional information about a claim or encounter. This implementation guide provides a detailed explanation of the transaction set by defining uniform data content, identifying valid code tables, and specifying values applicable for the business use of conveying Additional Information to Support a Health Care Claim or Encounter (275). This implementation guide describes a solution that includes the encapsulation of a Health Level Seven International (HL7) Standard (www.HL7.org) within the 275 transaction to support the exchange of clinical data. HL7 is an ANSI Accredited Standards Development Organization (SDO) whose domain is clinical and administrative data. See section 1.7.4 for additional details. This implementation guide is designed to assist those who send additional supporting information or who receive additional supporting information to a claim or encounter using the 275 format. Entities that use this implementation of the 275 include, but are not limited to, providers, health plans, third party administrators (TPAs), managed care service organizations, state and federal agencies and their contractors, plan purchasers, and any other entity that processes health care claims, manages the delivery of health care services, or collects health care data. Other business partners affiliated with the 275 include, but are not limited to, billing services, consulting services, vendors of systems, software and EDI translators, and EDI network intermediaries such as automated clearinghouses (ACHs), value added networks (VANs), and telecommunications services. |
1.2 Version InformationThis implementation guide is based on the October 2009 ASC X12 standards, referred to as Version 6, Release 2, Sub-release 0 (006020). The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 006020X314. 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 mode. Willing trading partners may use batch or real-time mode. |
1.3.2 Other Usage LimitationsThere are other usage limitations. The 275 transaction structure does not allow submission of additional information in support of more than one request for a health care claim or encounter. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each attachment of additional information. The 275 can support multiple sets of information for a single request for review. See Loop 2110B BDS Segment and the LX Segment at Loop 2000A for additional details. This implementation guide ONLY addresses using the 275 to support a health care claim or encounter. A separate implementation guide was developed for the 275 Additional Information to Support a Health Care Services Review. A trading partner agreement may be used to define time parameters for the submission of the solicited 275 and the unsolicited 275. The 275 must be received by the receiver within the specified time frame or the request will proceed through the process without the needed information. The ultimate disposition of the claim or encounter can include, but is not limited to, approval, rejection, or denial. As a result of the potential impact on transmission and processing times and storage capacity, trading partners may find it necessary to establish size limitations for the BDS Segment. It is recommended that the content of the BDS not exceed 64 megabytes. |
1.4 Business UsageThis 275 implementation guide is only used for communication from providers to payers to:
This Implementation Guide was written with the intent to send attachment data from provider to payer. |
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 Response to a Solicited Health Care Claim Request for Additional InformationA claim that is subjected to Medical or Utilization review during the adjudication process may be pended by the payer. The payer then solicits specific information to supplement or support the provider's request for payment of services. The payer's request for additional information may be service specific or apply to the entire claim. The request is received electronically using the 277, on paper or by other methods. The provider uses the 275 to respond. The 277 structure allows the payer to request additional information on multiple claims. However, the 275 transaction structure only allows the submitter to send additional information for one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim response. The 275 can accommodate multiple responses for a specific claim. See the LX segment section for additional details. In the 277, the payer must specify the period of time in which the provider has to respond to the request for additional information. The 275 response must be received by the payer within the specified timeframe, or the claim in question may proceed to the next phase of the payer's adjudication cycle. (The ultimate disposition of the claim or service line can include payment, rejection, or denial.) |
1.4.3 Unsolicited Additional Information to Support an 837When it is known at the time of billing that the additional information is required by the payer to adjudicate the claim, the provider may, in compliance with applicable regulations and trading partner agreements, submit an unsolicited 275. If done at the same time as the 837, the 275 may be sent in a separate interchange (ISA/IEA) or within the same interchange as the initial 837. A Trading Partner agreement may be used to define the time parameters for submission of the unsolicited 275 in a separate transaction. For example, a payer may specify that the claim will be adjudicated without the information if it is not received within a specific time frame. |
1.4.4 Information FlowsFigure 1.1 - Solicited 275 Transaction Flow illustrates the flow of information related to the solicited business flow for the 275 Transaction. Figure 1.1 - Solicited 275 Transaction Flow Arrow 1 Arrow 2 Arrow 3 Figure 1.2 - Unsolicited 275 EDI Transaction Flow - 837 and 275 in Same Interchange illustrates the flow of information related to the unsolicited business flow for the 275 Transaction when the 837 and the 275 are sent in the same interchange. Figure 1.2 - Unsolicited 275 EDI Transaction Flow - 837 and 275 in Same Interchange Arrow 1 Figure 1.3 - Unsolicited 275 EDI Transaction Flow - 837 and 275 in Different Interchanges illustrates the flow of information related to the unsolicited business flow for the 275 transaction when the 837 and the 275 are sent in two different interchanges. Figure 1.3 - Unsolicited 275 EDI Transaction Flow - 837 and 275 in Different Interchanges Arrow 1 Arrow 2 |
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. For convenience, the Wordbook definitions for the following business terms, which are used in this implementation guide, are listed below. Logical Observation Identifier Names and Codes (LOINC®) Code List The dash "-" character displayed in the LOINC® code (e.g., 18657-7) is part of the code. Note: Therefore the dash "-" character must not be used as a delimiter. |
1.6 Transaction AcknowledgmentsThe purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected. The ASC 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. 837 Health Care Claim (Institutional, Professional and Dental) In addition to the ASC X12 transactions listed above, the HL7 format standard is related to the 275. |
1.7.1 The Health Care Claim (837)Submitting a claim by using the 837 is the first step in the adjudication process. All data elements found on the original bill have their source from the provider's billing system. When it is determined that a claim needs additional information to complete the adjudication process, this information can be sent unsolicited in the 275 transaction. |
1.7.2 The Health Care Claim Service: Data Reporting (837)Reporting medical and cost data to state agencies, federal agencies, commercial carriers and those carriers doing business on behalf of state or federal agencies by using the 837 provides relevant health data for statistical analysis. When the 837 does not support all of the data that is necessary for data reporting purposes, the additional information can be sent in the 275 transaction. |
1.7.3 The Health Care Claim Request for Additional Information (277)Submitting a claim, by using the 837 or another format, is the first step in the claim adjudication process. All data elements found on the original bill have their source from the provider's billing system. When a claim requires supporting documentation to complete the payer's adjudication process, the payer can electronically request the information using the 277 transaction. Data from the original claim is included on the 277 to assist with locating the claim or the supporting information. |
1.7.4 Health Level Seven (HL7)The ANSI approved HL7 standard is used to convey the attachment content and is embedded in the 275. Relevant information can be found on the HL7 website (www.hl7.org). |
1.7.5 Application Advice (824)The 824 informs the submitter of the results of the receiving application system's data content edits of transaction sets. The Application Advice (824) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide. The Application Advice (824) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide. The "Application Reporting for Insurance" Implementation Guide is available for insurance industry use. It is recommended that the 824 transaction be used to acknowledge the 275 with the embedded HL7 attachment information. The 824 transaction provides the ability to acknowledge multiple standards. |
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.8.1 Time ParametersA Trading Partner agreement may be used to define the time parameters for submission of the unsolicited 275 in a separate transaction. For example, a payer may specify that the claim will be adjudicated without the information if it is not received within a specific time frame. |
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 ASC X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable ASC X12 standards and the implementation guide (also known as a TR3) itself. Should additional clarification of an ASC X12 implementation guide requirement be desired, two options are available.
ASC 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. ASC 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. ASC 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 State and Federal RegulationsASC X12 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. ASC 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 structure of the 275 and describes the positioning of the business data within that structure. Familiarity with ASC X12 nomenclature, segments, data elements, hierarchical levels, and looping structures is recommended. For a review, see X12.6 and Appendix C, EDI Control Directory. This implementation guide assumes the use of the ASCII format. If a format other than ASCII is used, then the appropriate conversions must be applied wherever ASCII is explicitly required. The contents of the BDS segment must be encoded as text. |
1.10.1 Data Needs For Business PurposeWhen a request for additional information is made, the payer supplies the parameters that assist the provider in locating the claim. These parameters are frequently the Provider's Assigned Claim Identifier, type of bill, medical record number, procedure code or revenue code, and the date of service. The provider is the source of this information. If the information is found on the original billed claim, the payer returns these data elements in the 277 transaction. If at the time of billing, the provider determines that additional information is needed for the payer to adjudicate the claim, an unsolicited 275 may be sent. In this usage, the provider supplies the parameters to enable the payer to identify the claim and/or the service(s) that the information supports. When the additional information is submitted in the 275, it will either be related to the entire claim or for a specific revenue line or service line. The segments used to submit the requested information are more clearly identified by specifying whether the information is related to the Claim Level or Service Line Level. The TRN segment is required and will either contain the payer's control number, if sent in response to a 277 or the provider's attachment control number, if sent with the 837. See Section 2 for detail segment usage. The 275 is divided into two tables. Table 1 contains transaction control information. Table 2 contains the detail information for the business function of the transaction. The following figure presents segments that may be used for Claim Level information Figure 1
The following figure presents segments that may be used for line level information Figure 2
|
1.10.2 Transaction Identification and PurposeThe Transaction Set Header Segment (ST) identifies the transaction set by using 275 as the data value for the transaction set identifier code data element, ST01. The originator of the transaction set assigns the unique control number ST02 which is shown here as 0001. In this example, the originator is the provider. ST03 carries the same value that is populated in GS08 which is the Implementation Version Identifier. For the 275 transaction this is 006020X314. The 275 transaction structure only allows the submitter to send additional information for one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim response. The Beginning Segment (BGN) indicates the transaction use. The Transaction Set Purpose Code value of "11" in the BGN01 indicates that this 275 is a response to a 277 Health Care Claim Request for Additional Information. A value of "02" indicates the unsolicited 275 is additional information sent to support an 837 claim or encounter. The originator of the transaction set assigns the unique reference number in BGN02 and the date of creation in BGN03. The Functional Group Header Segment (GS) provides additional identification of the business purpose of multi-functional transaction sets. See Appendix C, EDI Control Directory, for a detailed description of the elements in the GS segment. The following is an example of the transaction header segments. ST*275*0001*006020X314~ |
1.10.3 NM1 Loop Participants Identification StructureFor the solicited 275, the participants identified in the 275 are generally the payer, submitter (e.g., service bureau, clearinghouse, provider groups), provider, and patient. The Loop ID 1000 is repeated to define the participants involved in the transaction. The implementation guide specifies the participants in the subsequent loops within the transaction set and refers to these participants, respectively. The transaction participants must be in the following order:
The segments and data elements found in the 1000 Loop and the 2000 Loop describe the participants and their relationships. |
2.1 Presentation ExamplesThe ASC 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 ASC X12 Examples website at http://examples.x12.org. The ASC X12 Examples website provides convenient access to examples of ASC 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://products.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 ASC 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 ASC 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 ASC X12 standard supports usage of exponential notation, this guide prohibits that usage. |
Appendix D. Change SummaryThis Implementation Guide (006020X314) defines the X12 requirements for the Additional Information to Support a Health Care Claim or Encounter. It is based on version/release/subrelease 006020 of the ASC X12 standards. |