275 Transaction Set Listing
008020X343 Additional Information to Support a Health Care Services Review- Loop 1000A - INFORMATION SOURCE NAMERequired1
- Loop 1000B - INFORMATION RECEIVER NAMERequired1
- Loop 1000C - PATIENT NAMERequired1
- Loop 2000A - ASSIGNED NUMBERRequired>1
- Loop 2100A - ADDITIONAL INFORMATION SUBMITTED DATERequired1
- Loop 2110A - ASSOCIATED OBJECT TYPE IDENTIFICATIONRequired1
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*PI - FUNCTIONAL GROUP HEADER
ST*275 - 275 TRANSACTION SET HEADER
- This element must be populated with the guide identifier named in Section 1.2.
- This field 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.
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*ACV - INFORMATION SOURCE 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.
- Use this NM1 loop to identify the source of the additional information, that is, the creator and sender of the 275.
- When BGN01 = 02 or 22, this NM1 loop identifies the person or organization that initiated providing this patient information.
PER*IC - INFORMATION SOURCE 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.
REF - INFORMATION SOURCE SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
- If NPI is reported in NM109 of this loop then this REF segment is not used.
- If HPID or OEID is reported in NM109 of this loop then this REF segment is not used.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
NM1*40 - 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.
PER*IC - INFORMATION RECEIVER 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.
REF - INFORMATION RECEIVER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
- If NPI is reported in NM109 of this loop then this REF segment is not used.
- If HPID or OEID is reported in NM109 of this loop then this REF segment is not used.
The Social Security Number must be a string of exactly nine numbers with no separators.
For example, sending "111002222" would be valid, while sending "111-00-2222" would be invalid.
NM1 - 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.
- Use this segment to identify the patient as identified in the 278 Health Care Services Review associated with this 275 attachment.
- If the subscriber is the patient, use NM101 = "IL". If the dependent is the patient, use NM101 = "QC".
REF*EJ - PATIENT ACCOUNT NUMBER
At least one of REF02 or REF03 is required.
- The maximum number of characters to be supported for this qualifier is "20". Characters beyond the maximum are not required to be stored or returned by the receiving system.
- 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*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.
REF*2I - PATIENT EVENT TRACE NUMBER
At least one of REF02 or REF03 is required.
- In the unsolicited 275, this is the trace number assigned by the information source in the 2000E Loop of the 278.
- In the solicited 275, this may be the number provided in the original 278 Request, or a TRN added by the UMO in the 278 Response.
LX - ASSIGNED NUMBER
- 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.
- The LX segment can be repeated to send multiple documents to support an individual health care service review. The 275 transaction structure only allows the submitter to send supporting documentation for one health care service review in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each health care service review.
TRN - ATTACHMENT CONTROL TRACE NUMBER
- If this 275 is sent in response to the UMO's request for additional information, enter the TRN with the Attachment Control Number assigned by the UMO. This is the number that appears in PWK06 of the associated PWK segment in the Health Care Services Review Response.
- If this 275 is sent as an unsolicited attachment for a 278 Health Care Services Review Request or Notification, enter the TRN with the Attachment Control Number that appears in PWK06 of the 278 Health Care Services Review Request or Notification.
- When BGN01 = 11, this number is the Attachment Control Number assigned by the UMO.
- When BGN01 = 02 or 22, this number is the Attachment Control Number that the provider assigned.
- 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.
- 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.
REF - SERVICE TRACE NUMBER
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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
- 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, C022-08 and C022-10.
- 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.
- C022-10 is the attribute of the code in C022-02 from the same code list.
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.
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.
Data is required to be MIME packaged according to RFC-2557 (See http://www.rfc-base.org/rfc-2557.html).
Trading partners are required to support the following MIME types:
• MS Word Document - application/msword
• PDF - application/pdf
• Plain text - text/plain
• RTF Text - text/rtf
• HTML Text - text/html
• GIF Image - image/gif
• TIF Image - image/tiff
• JPEG Image - image/jpeg
• PNG Image - image/png
Other MIME types may be supported by trading partner agreement.
Submitters must not use multi-part MIME as the MIME type. Multiple documents are not supported in BDS03. To send multiple documents the 2000A LX Loop must be repeated. Please see the 2000A LX note.
OOI - ASSOCIATED OBJECT TYPE IDENTIFICATION
BDS*B64 - 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 Services Review (008020X343)JANUARY 2022 Copyright © 2008-22, X12 Incorporated, Format © 2008-22 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 Services Review Implementation Guide describes the use of the X12 Patient Information (275) transaction set 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 to all users of X12 Additional Information to Support a Health Care Services Review (275) Transaction Set that focuses on the use of the 275 to send additional information about a healthcare service review. It 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 the 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.4.4 - Unsolicited Additional Information to Support a 278 Health Care Services Review Notification and 1.7.4 for additional details. This implementation guide is designed to assist those who send or receive additional information in support of a healthcare service review using the 275 format. Entities that use this implementation of the 275 include insurance companies, utilization management organizations (UMO), third party administrators (TPA), managed care service organizations (HMO), state and federal agencies and their contractors, plan purchasers, and any other entity that processes a healthcare service review. Other business partners affiliated with the 275 include consulting services, vendors of systems software, EDI translators, and EDI network intermediaries such as automated clearinghouses (ACH), value added networks (VAN), 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 008020X343. 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 health care services review. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each request for review. The 275 can support multiple sets of information for a single request for review. See Loop 2110A 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 services review or notification. A separate implementation guide was developed for the 275 Additional Information to Support a Health Care Claim or Encounter. A trading partner agreement may be used to define time parameters for the submission of the solicited 275 and the unsolicited 275 when not sent in the same interchange (ISA/IEA) as the 278. The 275 must be received by the processing entity within the specified time frame or the request will proceed through the review process without the needed information. The ultimate disposition of the service review 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. |
1.4 Business UsageThe 275 transaction set is intended to meet the particular needs of the health care industry to send additional information about a health care service review either when a) responding to a request for additional information or b) submitting an original 278 Health Care Services Review Request or Response. This 275 is also used in support of a 278 Health Care Services Notification. This 275 is used to convey additional information to support the following business flows:
This 275 is used to send specific information to supplement an initial healthcare service review (unsolicited) or to provide requested (solicited) information for a service review. In either case, the additional information is required for the approval process to be completed. |
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 Solicited Response to a Health Care Services Review Request for Additional InformationWhen a medical or utilization review is performed during the healthcare service review additional information may be needed. The UMO (see X12 Wordbook for definitions) then requests specific information to supplement or support the provider's request for authorization of the services under review. The UMO request for additional information may be service specific or apply to the entire request. The 278 Health Care Services Review Response is used to transmit the request for additional information. The provider uses the 275 to respond to the 278 request (Figure 1.1). In order to facilitate the adjudication of the 278 Health Care Services Review Request, the UMO may negotiate with providers or include as part of their Trading Partner Agreement a specified time period in which the provider may respond to the request for additional information. The 275 response must be received by the UMO within the specified time frame or the request will proceed through the review process without the needed information. The ultimate disposition of the service review can include, but is not limited to, approval, rejection, or denial. |
1.4.3 Unsolicited Additional Information to Support a 278 Healthcare Service ReviewWhen it is known at the time of the request that additional information is required by the UMO in order to complete the healthcare service review, the provider may submit an unsolicited 275. If done at the same time as the 278, the 275 may be sent within the same interchange (ISA/IEA) as the initial 278 (Figure 1.2). This situation requires separate GS/GE Functional Groups for the 278 and the 275. It may also be sent in a separate interchange (Figure 1.3). The unsolicited 275 eliminates the need for the UMO to request additional information via the 278 Health Care Services Review Response. A trading partner agreement may be used to define time parameters for the submission of the unsolicited 275 when not sent in the same interchange (ISA/IEA) as the 278. See Chapter 3, Examples. |
1.4.4 Unsolicited Additional Information to Support a 278 Health Care Services Review NotificationThis transaction is used to move information between health care entities to enable referral or transfer of care, support continuity of care and facilitate third party and subrogation processes. A 278 Health Care Services Review Notification provides for the exchange of information provider to provider, UMO to provider, UMO to payer, payer to payer, payer to TPL entity, etc. Exchanged information includes data such as notification of a review or service outcome, documentation of services provided, supporting information for a specialty referral and acknowledgment/error reporting. |
1.4.5 Information FlowsThe business flow examples reference HL7 but the format to exchange electronic attachments is not limited to just HL7. |
1.4.5.1 Health Care Services Review Request and ResponseFigure 1.1 - Solicited 275 EDI Transaction Flow illustrates the path of information related to the solicited business flow for the 275 Additional Information to Support a Health Care Services Review. Figure 1.1 - Solicited 275 EDI Transaction Flow Arrow 1 Arrow 2 Arrow 3 Arrow 4 Figure 1.2 - Unsolicited 275 EDI Transaction Flow - 278 and 275 in Same Interchange illustrates the path of information related to the unsolicited business flow for the 275 when the 278 and the 275 are sent in the same interchange. Figure 1.2 - Unsolicited 275 EDI Transaction Flow - 278 and 275 in Same Interchange Arrow 1 Arrow 2 Figure 1.3 - Unsolicited 275 EDI Transaction Flow - 278 and 275 in Separate Interchange illustrates the path of information related to the unsolicited business flow for the 275 when the 278 and the 275 are sent in a separate interchange. Figure 1.3 - Unsolicited 275 EDI Transaction Flow - 278 and 275 in Separate Interchange Arrow 1 Arrow 2 Arrow 3 |
1.4.5.2 Health Care Services Review NotificationFigure 1.4 - Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Same Interchange illustrates the path of information related to the business flow for the 275 when the 278 and the 275 are sent in the same interchange. Figure 1.4 - Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Same Interchange Arrow 1 Arrow 2 Figure 1.5 - Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Separate Interchange illustrates the path of information related to the business flow for the 275 when the 278 and the 275 are sent in separate interchanges. Figure 1.5 - Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Separate Interchange Arrow 1 Arrow 2 Arrow 3 |
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. X12 278 Health Care Services Review - Request for Review and Response, and the X12 278 Health Care Services Review - Notification. Reference to specific versions of the 278 implementation standard is intentionally omitted to enable use of this transaction with any version of the 278. |
1.7.1 The Health Care Services Review Response (278)When a service request fails to complete the UMO's review, the UMO can respond with a 278 Health Care Services Review Response containing a request for additional information. Data from the original request is returned to the provider to facilitate locating the supporting information. The reason for the additional information is to aid in medical necessity decisions regarding the service requested. |
1.7.2 Health Care Services Review Request (278)When a request needs additional information to complete the review process, the provider can send an unsolicited 275 Additional Information to Support a Health Care Services Review in support of the 278 Health Care Services Review Request. |
1.7.3 Health Care Services Review Notification (278)The provider or information source can also send additional information in conjunction with a 278 Health Care Services Review Notification. For example, in a notification of discharge, the provider may need to attach information on the condition of the patient at the time of discharge; or a specialist may provide health care services outcome to the referring provider. |
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.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 structure of the 275 and describes the positioning of the business data within that structure. Familiarity with 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 UMO supplies the parameters that assist the provider in locating the documents needed for the healthcare service review. These parameters are frequently the Patient Account Number, Patient Event Tracking Number, Diagnosis Code and Procedure Code or Revenue Code. The provider is the source of this information. If the information is found on the original 278 Health Care Services Review Request, the UMO returns those data elements in the 278 Health Care Services Review Response that contains the UMO's request for additional information. If at the time of submitting the request for review, the provider determines that additional information is needed for completion of the review, an unsolicited 275 may be sent. In this usage the provider supplies the parameters to enable the UMO to match the supporting information to the 278 request for review. When the Additional Information is submitted in the 275, it will either be related to the entire health care services review or to a specific revenue line or service line. The following presents the developers' view of which segments are returned for patient event and service level information.
|
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 1001. 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 this 275 transaction the identifier is 008020X343. 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 278 Request for Additional Information Response. A value of "02" indicates that this is an unsolicited 275 with additional information for a 278 Healthcare Service Review. A value of "22" indicates that the information is in support of the 278 Health Care Services Review Notification. 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. See Appendix B, Nomenclature, for descriptions of data element separators (e.g., *) and segment terminators (e.g., ~). |
1.10.3 NM1 Loop Participants Identification StructureThe Loop ID: 1000 is repeated to define the participants involved in the transaction. The participants identified in the 275 are generally the information source, information receiver, and patient. The implementation guide specifies the participants in the subsequent loops within the transaction set and refers to these participants, respectively, in the following order and terms:
Loops 1000A, 1000B and 1000C contain the segments and data elements that describe the participants. Loop 1000A - Information Source Loop 1000B - Information Receiver Loop 1000C - Patient Patient REF Segment at the NM1 Level |
1.10.3 NM1 Loop Participants Identification StructureThe Loop ID: 1000 is repeated to define the participants involved in the transaction. The participants identified in the 275 are generally the information source, information receiver, and patient. The implementation guide specifies the participants in the subsequent loops within the transaction set and refers to these participants, respectively, in the following order and terms:
Loops 1000A, 1000B and 1000C contain the segments and data elements that describe the participants. Loop 1000A - Information Source Loop 1000B - Information Receiver Loop 1000C - Patient Patient REF Segment at the NM1 Level |
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 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 (008020X343) defines the X12 requirements for the Additional Information to Support a Health Care Services Review. It is based on version/release/subrelease 008020 of the X12 standards. |